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ABSTRACT : 

A system and method for exchanging data between two or more applications includes a 
data exchange engine and a number of adapters associated with a corresponding number 
of applications. Each of the adapters is customized to interface with a 
corresponding application and transforms data being transferred between the 
application and the data exchange engine. Data produced by a particular application 
is converted from a technology dependent form to a technology independent form by 
the corresponding adapter. In one embodiment, the format associated with a data 
stream is disassociated from the informational content of the data stream by the 
adapter. The informational content of the data stream is then transformed by the 
adapter into a common or generic format. The data exchange engine receives data in a 
technology independent form from each of its associated adapters and coordinates the 
routing of informational content to particular adapters associated with applications 
that have requested specific informational content. The adapters receiving the 
informational content from the data exchange engine transform the informational 
content having the common format into a data format compatible with, or specific to, 
their associated applications. A queuing mechanism is employed to construct a 
reliable asynchronous or pseudo- synchronous interface between disparate applications 
and systems. The data exchange engine may apply business rules or logic when 
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processing a requ^fc for particular informational ^fctent. User-specified routing 
logic may be applUB by the data exchange engine t^iispatch selected informational 
content to one or more destination applications. 
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ATTY-AGENT-FIRM: hIR.; Daniel D 



ABSTRACT : 



A method for multiple context analysis of software applications xn a multxprocessing 
(22 23), multithreaded computer environment utilizes instrumentatxon code xnserted 
(54' 55) 'into the applications. For each execution (67) of the applicatxon (60) , a 
context set is selected (62). Execution of the instrumented code (67) provxdes 
information for analysis in an instrumentation buffer (82) addressed by a reserved 
register (80) or buffer pointer. The operating system is responsxble for provxdxng 
in the reserved register (80) the address of the instrumentation buffer (82) 
appropriate for each instrumented context executed. When the applicatxon (60) xs 
done with an instrumentation buffer (82), the buffer may be processed by filter 
software (68). The combination of using a reserved register (80) and allowxng the 
operating system to keep track of relevant context switches allows applxcatxons tcp 
be instrumented (54, 55) for various context sets without the necessity of modxfyxng 
(53) or recompiling (52) the application software (60). 
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A method for multiple context analysis of software applications in a multiprocessing 
(22, 23), multithreaded computer environment utilizes instrumentation code inserted 
(54^ 55) into the applications. For each execution (67) of the application (60), a 
context set is selected (62) . Execution of the instrumented code (67) provides 
information for analysis in an instrumentation buffer (82) addressed by a reserved 
register (80) or buffer pointer. The operating system is responsible for providing 
in the reserved register (80) the address of the instrumentation buffer (82) 
appropriate for each instrumented context executed. When the application (60) is 
done with an instrumentation buffer (82), the buffer may be processed by filter 
software (68) . The combination of using a reserved register (80) and allowing the 
operating system to keep track of relevant context switches allows applications to 
be instrumented (54, 55) for various context sets without the necessity of modifying 
(53) or recompiling (52) the application software (60) . 
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ATTY-AGENT-FIRM: Sprung Horn Kramer & Woods 

ABSTRACT : 

A symbolic language data processing system comprises a sequencer unit, a data path 
unit, a memory control unit, a front-end processor, an I/O and a main memory 
connected on a common Lbus to which other peripherals and data units can be 
connected for intercommunication. The system architecture includes a novel bus 
network, a synergistic combination of the Lbus, microtasking, centralized error 
correction circuitry and a synchronous pipelined memory including processor mediated 
direct memory access, stack cache windows with two segment addressing, a page hash 
table and page hash table cache, garbage collection and pointer control, a close 
connection of the macrocode and microcode which enables one to take interrupts in 
and out of the macrocode instruction sequences, parallel data type checking with 
tagged architecture, procedure call and microcode support, a generic bus and a 
unique instruction set to support symbolic language processing. 
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ABSTRACT : 

A symbolic language data processing system comprises a sequencer unit, a data path 
unit, a memory control unit, a front-end processor, an I/O and a tnain memory 
connected on a common Lbus to which other peripherals and data \xnits can be 
connected for intercommunication. The system architecture includes a novel bus 
network, a synergistic combination of the Lbus, microtasking , centralized error 
correction circuitry and a synchronous pipelined memory including processor mediated 
direct memory access, stack cache windows with two segment addressing, a page hash 
table and page hash table cache, garbage collection and pointer control a close ^ 
connection of the macrocode and microcode which enables one to take interrupts in 
and out of the macrocode instruction sequences, parallel data type checking with 
tagged architecture, procedure call and microcode support, a generic bus and a 
unique insruction set to support symbolic language processing. 
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P-rif^f c;n mm;^rY T^yt, (8) : 

Fourth and fifth generation languages, termed 4GL and 5GL, would appear to offer a 
partial solution to the data interchange problem. These and other similar languages, 
such as those used to construct "business objects," are optimized around the 
construction of applications and user interfaces -for the primary purpose of 
providing powerful querying and reporting tools. The objects created by such 
languages typically define access paths to data residing in databases. The objects 
can be combined in various ways to create complex queries and for building powerful 
report generators. Fourth and fifth generation languages are not well suited for 
transporting vast amounts of data from one application to one or more other 
applications in a reliable and efficient manner. Although business objects 
constructed using 4GL and 5GL techniques do carry with them a certain amount of 
data, this data is typically data resulting from a query that is transported with an 
object definition for the purpose of performing additional analysis on the data. 

n-raw-ing n<agr!r-j pi- i nn T^_yt (15) : 

FIG. 18 is a class structure diagram showing public and non-public interfaces 
associated with various file based and database based queuing processes; 

Dfitailf^H DF>Rry-ipt---i on Text (51) : 

The Common Base Class is an abstract base from which the Common Object Class is 
derived. An inheritance tree graphically depicting the Common Base Class is shown in 
FIG. 17. The main purpose of this class is to provide a single object naming and 
typing mechanism to aid in object tree RparchRS and traversals. The Common Base 
Class is characterized in the following code- level example. 

ntahaile*^ DRRnr -ip1--ir>n Text (61) : 

The following Common Object retrieval methods are used internally by the 
GetAttributeValue ( ) and SetAttributeValue ( ) methods to search the attribute list 
of a Common Object and to locate a specific Common Attribute instance. These 
retrieval methods may be used by application developers as well. Each of these 
methods require a fully dot ( . ) delimited Distinguished Name and will recursively 
walk all relative levels of nesting to retrieve the relevant object /attribute. 

np>t-ai1pd DR.cir-yiption Text (134) : 

An error/event may occur at a very low level in the code (e.g., databa s e space 
exhausted) . It is important to report this low level event, but it is also important 
to report the context of what was trying to be achieved within the application when 
this low level error occurred. The application developer is provided with macros to 
define a context within the developer's code. The set of macros provided for this 
purpose include: INIT_CONTEXT; CONTEXT__BEGIN ; and CONTEXT_END. In general, every 
function using the context macros should first use the macro INIT_CONTEXT . It is 
noted that, if INIT_CONTEXT is not called before defining CONTEXT_BEGIN, the code 
may not compile. 

Deta-ileri DeRnr-i pt- i nn Text (135) : 

The beginning of a context may be defined using the macro CQNTEXT__BEGIN, and the end 
of a context can be defined using the macro CONTEXT_END, as is indicated in the 
following example. The CONTEXT_BEGIN macro takes the argument Context Number. This 
context number is used to access the Context Catalog of an application and to 
retrieve the context string. It is noted that nested contexts are generally not 
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allowed. If a C01»^^fcT_BEGIN is called before the p^fcious context is ended, an 
implicit CONTEXT_mB for the previous context is a^imed. The following example is 
provided : 

n^i-a-n<=>ri nfifirri pt-inn Tpyt (142) : 

The manrn rnNTFXT_ BEGlN . described in the following example, checks whether 
dx_init_context is initialized or not. The significance of this check is to make 
sure that the function does not compile if INIT_CONTEXT is not called before the 
first occurrence of CONTEXT_BEGIN . It then initializes the DX_Cont ex t Object pointer 
to point to a new DX_Context Object instance storing the context string specified by 
the context number argument. 

^)P>^a^^pH nf^.cirripl-inn TRxt (144) : 

The TTian-ro rnTsrTKyT_ RT<rD deletes the DX_ContextObject instance created by 
CONTEXT_BEGIN, as can be seen in the following example. 

np>tai1firf DPfinKiphinn Tpyt (147) : 

The following statistics are typically recorded when monitoring is performed on the 
queue: (1) number of the messages processed in the system input queue; (2) the 
average message cache time in the system input queue, by priority; and (3) the 
average message processing time from the system input queue, by priority. The 
following statistics are typically recorded when monitoring is performed on the disk 
space and HatabaRfi table space usage: (1) the percentage of the disk space usage if 
the queue storage type is FLATFILE; and (2) the percentage of the table space usage 
if the queue storage type is DATABASE . 

^^P>^a^^pr^ ^>pfirr^ p^^nn Tpxt (151) : 

The monitor writes the log file in the same format irrespective of whether the queue 
is file based or_databas£ based. The format of the report file is provide in Table 1 
below: 

np^t-a-ilfiH ^^f^Fir!T-ip^-^nn Tpxt (153) : 

When disk space and/or_databaa£ table space usage is being monitored (i.e., 
SYSTEM_INFO_MONITOR=ON) , the monitor writes the usage of the disk where the queue 
files located into an ASCII file on a regular time interval if the queue is file 
based. The name of the file follows the system file name schema (e.g., 
_SysInfo.Mon_Log) . The maiximum file size is defined in the system configuration 
file. After the file reaches its maximum size, the monitor moves it to a backup copy 
named _SysInfo.Mon_Log .bk and creates and writes the performance into the new 
_SysInfo.Mon_Log file. The system retains only one backup copy of the monitor log 
files. The format of the report file is give below in Table 2: 

nfit-a-ilf^d nf^fir:r-ipt--inn Text (154) : 

where. Time represents the time stamp of the record in the log file; and DiskUsage 
represents the percentage of the file disk usage if STORAGE_TYPE = FLATFILE . Again, 
the data fields are delimited by a comma. It is noted that the database table space 
usage is generally not available to the application user, such that only the system 
administrator has the privilege to view it. As such, the monitor does not perform 
monitoring for the database table space usage. 

Df^tailed De>fir-ri ption Tf^xt (157) : 

The Monitor Object is instantiated by the DX_SysConf igObject instance or by calling 
the static method DX_Monitor: : Instance ( ) directly. There is only one DX_Monitor 
thread running per executable component. The monitor thread is spawned whenever the 
MONITOR in the system configuration file is triggered to ON. The monitor thread 
exists until the MONITOR is triggered to OFF. The implementation of the monitor 
impacts three areas. The Queue Manager provides the queue performance data. The 
DX_SysConf igObject provides the configuration change handling and the monitor object 
instantiation. The DX_Monitor Object spawns or kills the monitor and generates the 
monitor log files or log tcible in the database. The methods added in the DX_Queue 
classes are listed below: 

npha-ilpH np*.qr•r^ ip^^ nn Tpvt (177) : 

Concerning data exchange system security, the basic security control is focused on 
the queue files access or the ^^a^abagfi taibles access. The file access control 
requires the application user to be in a specific user group. The user group should 
be set before the application runs. The datahasPi table access control requires the 
application users to have the correct user name and user password. The user name and 
user password may be set in the environment variables or be hard coded in the 
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application progr^^. In one embodiment, all appli^fcions share one databasf! user 
accoixnt. This usSRccount has privileges to creat^Update/ delete tables in the 
view. 

np>1-aH1f>H nfiRrriphinn T^xt (187) : 

A skeleton main( ) function is provided to illustrate the system initialization and 
startup procedures required for each component of the data exchange system 
application. This includes operations such as databasp: connection, system resource 
configuration, thread control, etc. In addition, a System Health Monitor thread is 
provided which, on a timed interval, polls all system resources to ensure that 
system operation can continue. This thread invokes the system checking operations 
System Configuration Object. The sample code provided below illustrates the ease of 
initializing system components and application operations. This sample is part of 
the DX_Engine executcible, which serves as the core of the data exchange system. 

np>ha-ilf*d Dg>sc!i- i phi nn Text (196) : 

A further description of a data exchange system queuing methodology in accordance 
with one embodiment of the present invention will now be described. In order to 
provide a clean "buffered API," a queued request approach is used. Use of interface 
queues allows the caller of the API to send its request irrespective of whether the 
engine core and another outgoing adapter are running. The queue interface approach 
of the instant embodiment also provides a mechanism for buffering the load that may 
be placed upon a server from multiple clients. It also provides the ability to scale 
the number of Hai-abasp servers that can process any given queue in parallel. 

nf^tailpd DescT-i pfi r>n Tf>xt (197) : 

As was discussed previously, two types of priority based queues are used, namely, 
the incoming Receive Queues and the outgoing Send Queues. Each outgoing adapter will 
have its own outgoing queue so that any interface specific translation or routing 
may be performed outside the engine core. Each instance of the DX_Engine executable 
has one or more input queues, although only one is allowed for file-based queues, 
and one or more output queues. An instance of the DX_QueueManager class is used as a 
central proxy to all queue access, and will be mutex protected and record-lock 
protected, for file-based implementation, or row lock protected, for database 
implementations, to prevent data contention. 

npha-ilpH nf^Rr-r-iph-inn Text (198) : 

Two types of queues are provided, file and database queues, both of which are fairly 
simple implementations that allow for a clean breakup to the API. Priority based 
queuing is provided so that requests of high importance can be serviced quickly. 
Multiple queues are used to provide this level of functionality, but the 
implementation is logically transparent to users. A user perceives that there is 
only one logic queue with objects of different priority in it. 

DPhailpd Description Text (199) : 

The file storage or Hai-ahasR tables for the queue are created at running time and 
deleted by queue administration process. There are four types of pre-defined 
priority: NONURGENT; NORMAL; URGENT; and INTERACTIVE in order of increasing 
priority. INTERACTIVE is the highest priority, which can block any request having 
other priorities. The priority algorithm ensures that the Dequeue operation always 
returns successfully when the queue is not empty, prevents starvation of lower 
priority entries, and ensures more frequent visits on higher priority queues. The 
priority algorithm is implemented on a weighted basis of each priority. 

npta-ilf^d Df^firr-iptiQn Text (200) : 

Support for parallel gateways is only available to a databasPi queue implementation. 
File-based queue implementations will not guarantee single delivery, i.e., one 
object might be dequeued by multiple process at the same time. All parallel access 
should be completely transparent to any participating gateway. The only areas of 
common resources between any parallel gateways are the Enqueue and Dequeue 
operations. The design of the Enqueue /Dequeue module ensures that parallel access is 
made possible without any deadlocks or duplicated queue entries by using the 
Hat-abagfi supplied row-level locking. 

np>^a^1pd npptcriptinn Text (201) : 

Since the external API is limited to the Enqueue/Dequeue API, the only limit to 
multiple access is the row-level table locking that the database supports. The file 
based queue mechanism uses simple file record-lock to protect from multiple updates 
to the file from multiple threads. The queue access operations for file-based 
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implementation ar^^read-saf e, such that all the (^g||:ations are mutex protected. 

npha-ilpH np>firrH p^^^>n TRxt (202) : 

The Queue Manager pxiblic interface makes use of the DX_QueueTransaction object for 
transaction control. The Enqueue ( ), Dequeue ( ), Commit ( ), and Rollback ( ) methods 
take pass- in argument of an instance of the DX_QueueTransaction class whxch belongs 
to a running thread. The transaction object contains an ordered list of operations 
performed in this transaction. For file-based implementations, all operations are 
maintained in buffered memory and are not written into file storage until commit 
time. For HahaHasfi implementations, the datahasfi provided rollback mechanism is 
employed, with each transaction using its own unique run-time database context. 

nf^t-a-ilfiH npgr-■r^p^^nn Tpxt, (221) : 

Dequeue ( ) attempts to find a queue object marked as NORMAL_OBJECT first from the 
memory buffer. If it can not find one, it will try to find one from the queue files. 
If Dequeue ( ) finds a queue object marked as NORMAL_OBJECT in a file, it creates a 
queue object, marks it as ACTIVE_OBJECT, inserts it into the memory buffer, and 
de-serializes the Common Object it refers to and returns the Common Object to the 
caller. During this process, if Dequeue ( ) can not de-serialize the Common Object, 
it will mark the queue object as DELETED_OBJECT in the queue file and continue its 
search. 

nf>t-a-i1fiH ^)P^F:rr ^p^^ nn Tfivh (223) : 

DX DBQueue is the_daLahase- based implementation of the DX_Queue interface. Its 
instance is mapped to a single table per queue at run-time. The order of the records 
is determined by the enqueue time stamp. All dequeue operations are sorted by 
priority and enqueue time stamp. An illustrative example of a DX_DBQueue 
implementation is provided as follows: 

nf^ha-ilpH npPir;'r-i p1--i nn T^yt. (227) : 

The invocation of the Enqueue ( ) and Dequeue ( ) API is effected by sending a request 
to the Queue Manager Object. In response to a request, the Queue Manager Object 
locates the correct queue and populates the operations to that queue object. When 
Enqueue ( ) is invoked, the object is placed into a buffer list and will not be 
collapsed into a data stream until Commit ( ) is invoked. Until the commit time, the 
DX IndexObject attribute of the DX_QueueOperation object retains the real meaning, 
which may be used in connection with a rollback operation if the commit operation is 
not successfully executed. For purposes of serialization, if the queue is a 
Ha^ahaP!R, the row- level locking provided by the database is used. If the queue is a 
file, file access control is used. When a Common Object is serialized at commit 
time! a priority tag is appended to its private attribute list, such that when the 
Common Object is dequeued, its priority can be easily determined. 

np^^a^1F>r^ npp;r-r HphT nn T^yh (228) : 

When Dequeue ( ) is invoked, the oldest entry with the proper priority is retrieved 
with the marshalled object then being instantiated as a Common Object using the 
DemarshaK ) method invocation. This mechanism provides database row-locking on read 
events to prevent parallel gateways reading the same queued requests. If the queue 
is file based, record lock is used. The logic to determine which priority queue 
should be invoked on implemented inside the DX_Queue object. 

n^a^a^1p^H np^Rf-ri p^ i nn Tpyt, (232) : 

Objects are stored and retrieved from a persistent store in an efficient manner. Two 
types of object storage, termed relational database storage and file storage, are 
implemented for this purpose. The object persistency is implemented using Marshal ( 
), DemarshaK ), and DeleteStorage ( ) methods of the DX_CommonObject class, where a 
parameter is passed to indicate storage type. A policy for object caching and 
sharing may also be employed. 

nphailpri nf^gnT- ipt-T nn T^yt (233) : 

Since ^^;=^^ahafiR implementation may vary among venders and file based persistency is 
needed, the object persistency model has been developed to be independent from any 
Hat-abaRf^ Storage technology. This approach involves collapsing the object into a raw 
binary data stream, and uses various headers to denote any marker and priority 
related information. The headers of a Common Object typically include OID and 
priority tag information. Table 4 provide below illustrates a how a Common Object 
may be stored in a typical database. 

DP^ha-ilfiH n^grT•^ p^^nn T^yl- (234): 
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As stated previou^^ all_datahaa£ access is hidden^aside the Enqueue ( ) and 
Dequeue ( ) methods'R DX_QueueManager and Marshal ( Demarshal ( ) , and 
DeleteStorage{ ) methods of DX_CommonObject . In one embodiment, all vendor specific 
access mechanisms may be delivered in a separate set of dfltahase enabled libraries. 

npl-ailpd Description Text (238) : ^ . , . ^ i / x ^ 

File-based ^^a^ahafiP access is invoked using the Marshal ( ), Demarshal ( ), and 
DeleteStorage ( ) methods from the Common Object with the output argument set to a 
file. Each object may be stored to a separate file where the filename incorporates 
the object ID. By using the object counter mechanism as a directory name, files can 
be spread evenly across a file system for better access time. 

n^t-a-ilf^ri ^)pfirr^ p^^or^ Tf^vt (240) : - j= ^ 

A transaction object should be created and destroyed as a local object of a thread. 
If neither Commit ( ) nor Rollback ( ) was called when a thread exits, all operations 
executed by this thread are rolled back. For a database implementation, the native 
transaction control mechanism of the database is used. For a file implementation, a 
transaction object contains a list recording of all operations in the current 
transaction. This memory buffer is used to buffer all queue operations and will not 
be written into file storage until commit time. Rollback ( ) removes the operations 
from that memory buffer for operations that have not been committed. Since Commit ( ) 
might fail. Rollback { ) also cleans the entries in the queue files and Common Object 
file for those operations that failed at commit time. 

^)P^^a^^pH DRflrr-i pt- i on Paragra ph Tahl r (2) : 

enum EclassTypes { DX_OBJECT = 0, DX_ATTRIBUTE , DX_LIST, DX_MULTIVALUE , DX_INTEGER, 
DX STRING, DX STRINGVAL, DX_DATE, DX_TIME, DX_REAL, DX_BLOB, DX_BLOBVALUE , 
DX~VERSION, DX OID CLASS } ; enum EretumCodes { N0T_FOUND = 0, SUCCESS, FAILED, 
TIME OUT, ACCESS_DENIED, DUPLICATE_OB JECT , N0_0BJECT, N0_ATTRIBUTE , INVALID_ATTRVAL, 
INVALID_ARGS, INVALID_OPERATION, SYSTEM_ERR0R }; enum EstorageTypes { FLATFILE = 0, 
naTARAfiE }; enum ElistType { PUBLIC = 0, PRIVATE } ; static const int 
MAX NAME_LEN=255; static const int MAX_DOTTED_NAMELEN=8096 ; static const int 
MAX~MULTI VAL=255; static const int MAX_BLOB_SIZE=2048 ; static const int 
OID~LEN=128; Static const int MAX_FILE_NAME=256 ; static const int MAX_PID_LEN=12 ; 
static const int MAX_LINE_SIZE=100 ; 

Df^hailpH nf^grr -i p^ -i on Paragraph Table (3) : 
class: DX_CommonObject : public DX_CommonBase { 

RWDECLARE_COLLECTABLE(DX_CommonObject) ; friend class DX_ListObject ; friend class 
DX FileSubQueue; public: virtual . about .DX_CommonObj ect () ; // Constructors 
/**■***************************************************************/ //If name==NULL, 
the name is set to "NOT SET". //If name is ""or contains a "." it will be set to 
"INVALID NAME" /*****************************************************************/ 
DX CommonObj ect (const char* name=0) ; 

/**■***************************************************************/ //Create a copy 
of an entire DX CommonObj ect , //but with it's own unique OID value 

/************* *T* *************************************************/ DX_CommonOb j ect * 
Clone 0; /*****************************************************************/ //All 
AddAttribute and AddPvt At tribute methods take ownership of //the pointers passed in 
to them. Do NOT delete the pointers after //a call to AddAttribute and 
AddPvtAttribute. The pointers will be //deleted when the container DX_CommonObject 
or DX ListObject is deleted. // //NOTE: When using the following two methods for 
creating a DX_STRING attribute // // AddAttribute (const char* name, const int type, 
const void* value) // and AddPvtAttribute (const char* name, const int type, const 
void* value) // // the value is defaulted to be of type const char* and not UNICHAR* 
// Misuse will lead to unexpected behavior. 

/*****************************************************************/ EretumCodes 
AddAttribute (DX_CommonAt tribute* newAttr) ; EretumCodes AddAttribute (DX_ListObj ect* 
newAttr) ; EretumCodes AddAttribute (DX_CommonObj ect* newAttr) ; EretumCodes 
AddAttribute (const char* name, const int type, const void* value); EretumCodes 
AddPvtAttribute (DX_CommonAttribute* newAttr); EretumCodes 
AddPvtAttribute (DX_ListObj ect* newAttr); EretumCodes 

AddPvtAttribute (DX_CommonObj ect* newAttr); EretumCodes AddPvtAttribute (const char* 
name, const int type, const void* value); 

*****************************************************************/ 
/ /DeleteAttribute and DeletePvtAttribute will remove the named attribute //from the 
container DX CommonObj ect or DX_ListObject and delete the named //attribute's 
pointer /****"*************************************************************/ 
EretumCodes DeleteAttribute (const char* name); EretumCodes 
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DeletePvtAttribut^knst char* name) ; 

/****************^^^********* ***************** *****/ 
//RemoveAttribute will remove the named attribute from the container 
//DX CommonObject or DX ListObject but will not delete the named //attribute's 
pointer /*****************************************************************/ 
EretumCodes RemoveAttribute (const char* name); EretumCodes 
RemovePvtAt tribute (const char* name) ; 

/*****************************************************************/ //Do NOT delete 
the pointer that is returned to you, it still is owned by //the container 
DX_CommonObject or DX_ListObject . You CAN use the any of //the attribute class 
methods for the pointer. 

/*****************************************************************/ void* 
GetAttribute (const char* name); void* GetPvtAt tribute (const char* name); void 
PrintContentsO ; //The caller of Demarshal is responsible for object's memory 
allocation static DX_CommonObject* Demarshal (char* ObjOid, int type, int 
Context Index ) ; EretumCodes Marshal (int type, int Context Index) ; static EretumCodes 
DeleteStorage( const char* oidVal, int type, int Context Index ) ; //The caller of 
GetOID is responsible for deleting the memory of the returned char* char* GetOIDO; 
EPriorityCode GetPriorityO ; protected: void* Find(const char* name); static 
EretumCodes RestorePersistentObject (const char* oidVal) ; static EretumCodes 
DeletePersistentObject (const char* oidVal, int type); private: //Data Members 
DX_ListObject* PrivateList; DX_ListObject* PublicList; static void 

Delete (RWDlistCollectables* list); static int Copy (RWDlistCollectables* dest, const 
RWDlistCollectables *src) ; static EretumCodes CopyPersistentObj ect (char* filename); 
static EretumCodes CopyFile (char* filename, char* copyf ilename) ; void 
saveGuts (RWFile& file) const; void saveGuts (RWvostream& stream) const; void 
restoreGuts (RWFile& file); void re storeGut s (RWvi streams stream); const int checkO 
const; DX_Boolean updateListOids(DX_ListObject* Plist, DX_OID *Poid) ; DX_Boolean 
updateObjectOids (DX_CommonObject* Pob j , DX_OID *Poid) ; DX_Boolean 
ValidateNaming (const char* name); # i fde fDX_D AT ABASE EretumCodes 
Insert IntoTable (char* filename, int Context Index) ; static EretumCodes 
Ret rieveFromTable (char* filename, char* oid, int Context Index ) ; EretumCodes 
UpdateTable(char* filename, int Context Index ) ; #endif //use to cal . the number of 
bytes needed to store an object using RWFile RWspace binaryStoreSize ( ) const;}; }; 

npta-ilpH np^Hr.r-ipf inn Pa-ragr aph Tahl (42) : 

enum EstorageTypes { FLATFILE = 0, DATABASE }; enum EQueueOperation { ENQUEUE = 0, 
DEQUEtJE }; static const int NUM_PRIORITIES = 4; enum EPriorityCode { NONURGENT = 0, 
NORMAL, URGENT, INTERACTIVE }; 
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Brief Summary Text (15) : 

Process monitoring, tracing, and logging are provided to track the progress of data 
passing through the data exchange engine and to detect and correct processing 
errors. In the case of a processing anomaly, the data exchange engine effects a 
rollback of failed transactions to preclude the loss of data. Performance 
statistics may also be provided. 

Detailed Description Text (39): 

Also shown in FIG. 9 is a statistics monitor module 264 and an associated 
statistics log 276 which are used to provide monitoring and tracking of data as it 
moves through the data exchange system. The statistics monitor module 264 also 
provides historical performance information on queues and historical information on 
system resource usage. As will be described in greater detail hereinbelow, the 
statistics monitor module 264 provides a means for logging and tracing a given 
application. Logging reveals the state of the application at the time of an error, 
while tracing provides a description of all software events as they occur. The 
tracing information may be used for tracking the application, state, and other 
related operations. The tracing information may be used in conjunction with the 
logging information to determine the cause for an error since it provides 
information about the sequence of events prior to an error. 

Detailed Description Text (109) : 

Having discussed in detail various aspects of the Common Object design hereinabove, 
a more comprehensive description of a data exchange system infrastructure in 
accordance with one embodiment of the present invention is provided below. The 
various aspects of the system infrastructure described in greater detail 
hereinbelow include: configuration management; logging and tracing ; context 
definition; performance and statistics monitoring; administration and maintenance; 
security; processing thread pool; internationalization; and process procedures. 

Detailed Description Text (111) : 

Parameters of a component, such as trace/log settings, may be changed at run time. 
For this purpose, configuration management tools provide a command line interface 
and a Web interface for viewing and configuring various parameters at run time. It 
is noted that various components of the data exchange system may be running on 
different machines. Thus, the configuration management utility provides the ability 
to view and modify the parameters of a component running on a different machine, 
possibly on a different platform. The Web interface of the configuration management 
utility provides the requisite connectivity to a remote machine and provides the 
capability for performing remote configurations. 

Detailed Description Text (112): 

When initiated, a component creates an instance of a System Configuration Object 
(DX_SysConf igObject) that stores the current parameter settings. The component also 
registers for a Signal/Event so that it is informed of changes to the configuration 
using the dynamic configuration command line interface/web interface. When a user 
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wants to change the run time parameters of a component (identified by the process 
ID and the machine on which it is running) , a signal/event is sent to the component 
to update its configuration. A signal/event handler invokes the Reconf igParameters 
( ) method on the DX_SysConf igOb j ect, which takes care of reconfiguring the various 
controller objects, such as DX TraceLogObject, DX_QueueManager , and 
DX_ThreadController for example. The System Configuration object, 
DX SysConf igOb j ect , is a singleton object that initializes and controls the 
configuration of a component in the data exchange system, such as logging / tracing 
levels, thread controller, queuing, and performance monitoring. A singleton object, 
as understood in the art, refers to a C++ nomenclature meaning that only a single 
instance of the class may exist within a single executable. A singleton object is 
most commonly used when controlling system wide resources. 

Detailed Description Text (118) : 

The logging and tracing utility provides for logging and tracing during execution 
of a component. As discussed previously, logging reveals the state of the component 
at the time of an error, while tracing provides a description of all software 
events as they occur. The tracing information may be used for tracking the 
component-state, and other related operations. It may be used in conjunction with 
the logging information to determine the cause of an error, as it provides 
information about the sequence of events prior to an error. 

Detailed Description Text (119) : 

A component that intends to record a log /trace message indicates the category to , 
which the message belongs. The log and trace messages are recorded in two different 
files whose names are derived from the name of the application, as indicated in the 
following example: (<componentName><pid> . log and <componentName><pid> . trc, 
respectively) 

Detailed Description Text (121) : 

Tracing involves recording three types of messages, which are typically specified 
by the developer. The INFORMATION (sys_INFO and APP_INFO) message provides a record 
of specific events that occur during the execution of the component, such as 
beginning of a new control thread. SYS_INFO is used within the DX libraries and 
APP_INFO is to be used by applications using the DX libraries. The TRACE (SYS TRACE 
and APP TRACE ) message provides a detailed record of various software events that 
occur during the course of normal execution of the component. SYS _TRACE is used 
within the DX libraries and APP _TRACE is to be used by the applications using the 
DX libraries. The AUDIT message provides a record of all the information sent or 
received by various components of the data exchange system. 

Detailed Description Text (122) : 

A configuration file is used to store trace/log related parameters in one or more 
directories. The TRACE LOG DIR directory is used to store the trace/log files. If 
this parameter is not specified, it is set by default to the current working 
directory. The tracing level associated with the SYS_INFO, APP_INFO, SYS TRACE, 
APP _TRACE, and AUDIT parameters may be specified as ON or OFF. The default value 
for any trace level is OFF. The WARNING, MAJOR, and CRITICAL parameters may also be 
specified as ON or OFF. It is noted that there exists a hierarchical relationship 
between these three error levels. For example, if WARNING is ON, it implies that 
all the error levels are ON. If MAJOR is ON, then CRITICAL is ON. 

Detailed Description Text (123) : 

The TRACE LOG SIZE parameter controls the maximum size of a trace/log file. When 
the trace or log file reaches the specified size, it is moved into the files named 
<componentname><pid>. trc.bk or <componentname><pid> . log . bk, respectively. The 
default value for the trace/log file size is lOOK bytes. 



Detailed Description Text (124) : 

A trace statement is typically used to write a developer specified string to the 
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<ComponentNaine><pid>. trc file if the trace category specified by the developer, 
which is generally hard coded in the program, is ON at run time. A log statement is 
generally used to write a specified error message to <ComponentName><pid> . log file 
if the category specified by the developer, which is generally hard coded in the 
program, is set to ON at run time. It is noted that the developer typically 
specifies an error number that is used to retrieve the error message from an 
external Message Catalog. 

Detailed Description Text (125) : 

In order to write a message into the log /trace file, the developer may use the 
macro DX_TL as shown below: DX_TL (DX_ARGS, Category, StringToLog/ErrorNumber [ , arg 1 
[,arg2]]); 

Detailed Description Text (126) : 

The macro DX_ARGS includes parameters such as filename, line number, time and 
thread ID that are automatically written into the trace/log messages. Category is 
specified by the following enumerated data types: 

Detailed Description Text (128): 

StringToLog is specified by the developer as a trace message and is written into 
the <ComponentName><pid>. trc file (type char *) . For Example, an AUDIT message 
could include the details of a Common Object typically stored as a formatted 
string. ErrorNumber is specified by the developer for a log message (e.g., when the 
category is CRITICAL, MAJOR or WARNING) , and is used to index into a Message 
Catalog to retrieve the error message to be logged. The error message numbers are 
defined as an enumerated type as shown below: 

Detailed Description Text (130) : 

A component using the Tracing/Logging Utility needs to include the following 
statement: #include " traceLogUtil . h " . The definition of DX TraceLogObj ect and other 
related definitions are provided as follows: 

Detailed Description Text (132) : 

The Write ( ) method in the DX TraceLogObject calls WriteFormattedTraceLog ( ) of 
DX _TraceLogFormatControl Object to write to the trace/log stream in a specific 
format. Thus, the implementation of the DX _TraceLogFormatCont rol object may be 

_j^har. j S i ' I n ^ 1 I . i im ui^ Hai-P^ the needs of users who would want to implement a desired 
formatting style^^he contents of Trace/Log messages that are logged include the 

-^crTlowing: L'Stegory; File name; Line Number; Thread ID; Time; and Context. 

Detailed Description Text (133) : 

The System Configuration Object contains an instance of the Trace/Log Object, which 
is initialized with parameter values specified in the Configuration file. When the 
user modifies the Trace/Log parameters at run time, typically by use of the 
DX_ConfigSet command, a signal is sent to the applicable component which calls the 
method ReconfigParameters ( ) on the System Configuration Object to re-initialize 
the parameters. This method, in turn calls Reconf igParameters ( ) on the 
DX _TraceLogOb j ect . 

Detailed Description Text (139) : 

The method GetContextStr ( ) is called by every log /trace statement to include the 
current context information in the message. GetContextFromCatalog ( ) is used to 
retrieve the Context information from the context catalog. 

Detailed Description Paragraph Table (22) : 

enum DX_TL_CATEGORY { CRITICAL, MAJOR, WARNING, SYS_INFO APP_INFO SYS TRACE, 
APP _TRACE, AUDIT } ; 

Detailed Description Paragraph Table (24) : 

enum DX INDICATOR { ON, OFF }; class DX TraceLogObj ect { friend class 
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DX_SysConfigObject; public: //cannot delete the pointer returned //call 
Deletelnstance ( ) static DX Trace LogObj ect* Instance (char * component Name, 
DX_INDICATOR *ini tTrcLogCatInd, char* initTrcLogDir , long initTrcLogSize) ; //cannot 
delete the pointer returned //call Deletelnstance ( ) static DX TraceLoqObj ect * 
Getlnstance( ); static void Deletelnstance ( ); //used to write a trace/log message 
specified by msg //to the //.trc/.log file void Write ( char *filename, int lineno, 
char* context, char* threadid, DX_TL_CATEGORY ctg, char* msg, char* argl=0, char* 
arg2=0) ; //used to write a log message specified by errNo // (access Message 
Catalog //to get the message) to the. log file void Write ( char *filename, int 
lineno, char* context, char* threadid, DX_TL_CATEGORY ctg, EerrorNumber errNo, 
char* argl=0, char* arg2=0) ; private: static DX TraceLoqOb ject* instance; //default 
constructor - does nothing DX _TraceLoqObi ect ( ); //constructor used to initialize 
the Tracing/ logging object DX TraceLogObject (char *componentName, DX_INDICATOR 
*initTrcLogCatInd, char* initTrcLogDir, long 

initTrcLogSize); //destructor . about . DX TraceLogObj ect ( ); //called by 
sysConf igObject when a deconfigset //command modifies any parameters void 
Reconf igParameters (char* componentName, DX_INDICATOR *newTrcLogCatInd, char* 
newTrcLogDir , long newTrcLogSize ) ; //to retrieve the message from the catalog char* 
GetMessageFromCatalog (int errNum, char* argl, char* arg2); //to store the settings 
of the trace/log levels DX_INDICATOR trcLogCategoryInd [DX_NUM_CATEGORIES] ; 
DX_Boolean CheckLogFileSize (of stream &logStream, char *fileName, long size); void 
CloseLogFile (of stream &logStream) ; DX_Boolean OpenLogFile (of stream &logStream, char 
*fileName); //the out streams for the trace and log files ofstream trcStream; 
ofstream logStream; int logStreamlsOpen; int trcStreamlsOpen; long logSize; char 
traceFileName[MAX FILE NAME]; char logFileName [MAX_FILE_NAME] ; DX_Mutex* trcLock; 
DX_Mutex* logLock; DX_Mutex* trclogParamsLock; }; class DX TraceLogFormatControl 
{ public: static void WriteFormattedTraceLog (ofstream& outStream, char *category, 
char *time, char *filename, int lineno, char* threadid, char *message) ; ); 

Detailed Description Paragraph Table (25) : 

Funcl( ) { INIT_CONTEXT; ... CONTEXT_BEGIN ( EcontextO ) ; // all the trace/log 
statements in this region will // have the context information // specified by 
EcontextO. CONTEXT_END; CONTEXT_BEGIN (Econtextl ) ; // in Econtextl CONTEXT_END; } 

CLAIMS : 

7. The method of claim 1, further comprising tracking each of the data streams 
during converting, identifying, or transforming operations. 

17. The method of claim 10, further comprising tracking the data during converting, 
identifying, or transforming operations. 

25. The method of claim 19, further comprising: tracking processing of the 
information having the generic format; and logging errors occurring during the 
processing of the information having the generic format. 

49. The medium of claim 44, further comprising tracking the data during converting, 
identifying, or transforming operations. 

56. The system of claim 51, further comprising means for tracking the data during 
converting, identifying, or transforming operations. 
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Detailed Description Text (128) : 

StringToLog is specified by the developer as a trace message and is written into 
the <ComponentName><pid> . trc file (type char *). For Example, an AUDIT message 
could include the details of a Common Object typically stored as a formatted 
string. ErrorNumber is specified by the developer for a log message (e.g., when the 
category is CRITICAL, MAJOR or WARNING) , and is used to index into a Message 
Catalog to retrieve the error message to be logged. The error message numbers are 
defined as an enumerated type as shown below: 

Detailed Description Text (216) : 

Each queue is stored into two categories of files. Each Common Object will be 
stored as a single file, named by its OID. These files will be evenly distributed, 
on the modula of 256, into different sub-directories for purposes of even file 
distribution and performance. These files are generated when the object is 
serialized. The index of each Common Object is stored in a series of indexed files, 
indexed from 0 to 9999, which is the physical and persistent storage for the logic 
queue. Each file may contain up to 100 index records. The order of the index record 
is defined by the offset of that record to the beginning of the file. 

Detailed Description Text (218) : 

The enqueue operation appends a record at the end of the newest file. The dequeue 
operation attempts to find a valid record from the in te^na"!--^ memory buffer. If one 
is not found, the dequeue operation will then read one^index- ob j ec^ f rom file into 
the memory buffer. A status field is used to determine the validity of the record. 
An object can be marked as follows: NEW_OBJECT (object is enqueued but not 
committed yet); ENQUEUED_OBJECT (object is enqueued and committed); NORMAL_OBJECT 
(valid object in the queue storage or a the object was rolled back in the memory 
buffer); ACTIVE_OBJECT (object is read from file into memory buffer and being 
processed); or DELETED_0 EJECT (object has been processed after it is dequeued or it 
was marked as so in the file) . The object in the file storage will only be labeled 
DELETED_OBJECT after the transaction is committed. An implementation example is 
given as follows: 

Detailed Description Text (225) : 

The DX_IndexObject class is important for all the queue operations. It is used to 
uniquely identify the location at which a Common Object is stored, and is further 
^feised for internal routing of all queue requests. The DX^IndexObrj'ects^class is member 
^of the DX_QueueObject class and DX_Qu^u^p_eration^_^,ass===^I^t^ include queue 

name, queue priority, storage type, "^iiJ^^Jia]^^ file indeK\^ -^recojodi offset, and 
record sequence. An illustrative example of a DX_IridexObj ect implementation is 
provided as follows; 

Detailed Description Text (230) : 

The Error Queue is needed to provide storage for run-time processing failures. 
Since the entries are stored in a queue with an index to the object that generated 
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the error, the processing logic can decide what further operations should be 
performed. The implementation of Error Queue is as an instance of DX__Queue. Since 
no priority issue is involved in Error Queue, the priority argument of the queue 
operation is relegated to a dummy argument, and only one of the internal child 
queues need be used. 

Other Reference Publication (26) : 

Product Literature, "MQSeries Business Partners Index, " 

http://www.software.ibm.com/ts/mqseries/partners/partner.html, 1 pg . (Feb. 1998). 
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DOCUMENT-IDENTIFIER: US 6453356 Bl 
TITLE: Data exchange system and method 



Abstract Text (1) : y 
A system and method for exchanging data between two or more applioi^tions includes a 
data exchange engine and a number of adapters associated with aycorresponding 
number of applications. Each of the adapters is customized to ^^terf ace with a 
corresponding application and transforms data being transferred between the 
application and the data exchange engine. Data produced by ^ particular application 
is converted from a technology dependent form to a technoLogy independent form by 
the corresponding adapter. In one embodiment, the f ormat^^ssociated with a data 
stream is disassociated from the informational content y6f the data stream by the 
adapter. The informational content of the data streari^^s then transformed by the 
adapter into a common or generic format. The data exchange engine receives data in 
a technology independent form from each of its associated adapters and coordinates 
the routing of informational content to particuly^ adapters associated with 
applications that have requested specific informational content. The adapters 
receiving the informational content from the darca exchange engine transform the 
informational content having the common format into a data format compatible with, 
or specific to, their associated applications. A queuing mechanism is employed to 
construct a reliable asynchronous or pseuda^synchronous interface between disparate 
applications and systems. The data exchan^ engine may apply business rules or 
logic when processing a request for particular informational content. User- 
specified routing logic may be appliedyoy the data exchange engine to dispatch 
selected informational content to one^r more destination applications. 

Brief Summary Text (8): / 

Fourth and fifth generation langu^es, termed 4GL and 5GL, would appear to offer a 
partial solution to the data intoi^change problem. These and other similar 
languages, such as those used tar construct "business objects, " are optimized around 
the construction of applicatioi^ and user interfaces for the primary purpose of 
providing powerful querying ajld reporting tools. The objects created by such 
languages typically define a/cess paths to data residing in databases . The objects 
can be combined in various ifays to create complex queries and for building powerful 
report generators. Fourth /nd fifth generation languages are not well suited for 
transporting vast amountyof data from one application to one or more other 
applications in a reliable and efficient manner. Although business objects 
constructed using 4GL a,ftd 5GL techniques do carry with them a certain amount of 
data, this data is tyn^cally data resulting from a query that is transported with 
an object definition ytor the purpose of performing additional analysis on the data. 

Brief Summary Text/ (9) : 

There exists a keenly felt need for a data exchange system and methodology that is 
capable of excha/ging data of varying size, content, and format between dissimilar 
systems and app/ications . There exists a further need for such a system and 
methodology th^ is independent of any current or future technology. The present 
invention fulfiflls these and other needs. 
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Brief Summary Text (11) : 

The present invention is directed to a system and method for excfefSnging data 
between two or more applications. The data exchange system inpdAides a data exchange 
engine and a number of adapters associated with a corresponding number of 
applications. Each of the adapters is customized to intej5^ce with a corresponding 
application and transforms the data being transferred hfetween the application and 
the data exchange engine. Data produced by a partici^l^r application is converted 
from a technology dependent form to a technology independent form by the 
corresponding adapter. 

Brief Summary Text (12) : 

In one embodiment, the format associated with a data stream is disassociated from 
the informational content of the data strream by the adapter. The informational 
content of the data stream is then tra^isformed by the adapter into a common or 
generic format. The data exchange en^ne receives data in a technology independent 
form from each of its associated a^pters and coordinates the routing of 
informational content to particular adapters associated with applications that have 
requested specific informational content. The adapters receiving the informational 
content from the data exchang^ engine transform the informational content having 
the common format into a da^ format compatible with, or specific to, their 
associated applications. one embodiment, a queuing mechanism is employed to 
construct a reliable as^chronous or pseudo-synchronous interface between disparate 
applications and systems . 

Drawing Description Text ( 15 ) 

FIG. 18 is a class structure diagram showing public >^d non-public interfaces 
associated with various file based and database b^sed queuing processes; 

Detailed Description Text (119) : 

A component that intends to record a loq/t.j^oe. message indicates the category to 
which the message belongs. The log and t^ace messages are recorded in two different 
files whose names are derived from the/name of the application, as indicated in the 
following example: (<coraponentName><pad> . log and <componentName><pid> . trc, 
respectively) 

Detailed Description Text (120J 

The possible severity levels y^r logging various diagnostic messages are as 
follows. The CRITICAL sever^y level indicates that the component is in a critical 
state and cannot proceed properly until the problem is attended to. The MAJOR 
severity level indicates/ that a particular activity/operation of the component has 
failed. However^^ this JffTay not effect other activities that may continue to run. The 
WARNING severity lev^ indicates that the component acted in an unexpected manner. 
This may be someti]j^g minor, such as a component receiving an invalid message. 

Detailed Description Text (128) : 
%i^'!)StringToLog is specified by the developer as a trace message and is written into 
y the <ComponentName><pid> . trc file (type char *). For Example, an AUDIT message 
could include the details of a Common Object typically stored as a formatted 
string. ErrorNumber is specified by the developer for a log message (e.g., when the 
category is CRITICAL, MAJOR or WARNING), and is used to index into a Message 
Catalog to retrieve the error message to be logged. The error message numbers are 
defined as an enumerated type as shown below: 

Detailed Description Text (134) : 

An error/event may occur at a very low level in the code (e.g., database space 
exhausted) . It is important to report this low level event, but it is also 
MO '4?)^ important to report the context of what was trying to be achieved within the 
^application when this low level error occurr.ed. The application developer is 
provided with macros to define a context within the developer's code. The set of 
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macros provided for this purpose include: INIT_CONTEXT; CONTEXT_BEGIN; and 
CONTEXT_END. In general, every function using the context macros should first use 
the macro INIT_CONTEXT . It is noted that, if INIT_CONTEXT is not called before 
defining CONTEXT_BEGIN, the code may not compile. 

Detailed Description Text (135): >^ 

The beginning of a context may be defined usi^>g the macro CONTEXT_BEGIN, and the 
end of a context can be defined using the marcro CONTEXT_END, as is indicated in the 
following example. The CONTEXT_BEGIN mac;?C takes the argument Context Number. This 
context number is used to access the G^mtext Catalog of an application and to 
retrieve the context string. It is rxited that nested contexts are generally not 
allowed. If a CONTEXT_BEGIN is (z^/L^^ before the previous context is ended, an 
implicit CONTEXT_END for the pr^ious context is assumed. The following example is 
provided: 

Detailed Description Text ^47) : 

The following statistics are typically recorded whea^monitoring is performed on the 
queue: (1) number of the messages processed in thp^ystem input queue; (2) the 
average message cache time in the system input i^eue, by priority; and (3) the 
average message processing time from the syst^ input queue, by priority. The 
following statistics are typically recorded/when monitoring is performed on the 
disk space and database table space usage^ (1) the percentage of the disk space 
usage if the queue storage type is FLATFILE; and (2) the percentage of the table 
space usage if the queue storage type/is DATABASE. 

Detailed Description Text (151) : 

The monitor writes the log file in the same ^^rmat irrespective of whether the 
queue is file based or database based. Th^^ormat of the report file is provide in 
Table 1 below: 

Detailed Description Text (153) : 

When disk space and/or database table space usage is being monitored ( i . e . , 
SYSTEM_INFO_MONITOR=ON) , the monitor writes the usage of the disk where the queue 
files located into an ASCII file on a regular time interval if the queue is file 
based. The name of the file follows the system file name schema (e.g., 
<AppName>_SysInf o .iy[on_Log) . The maximum file size is defined in the system 
configuration file. After the file reaches its maximum size, the monitor moves it 
to a backup copy named <AppName>_SysInf o .Kon_Log . bk and creates and writes the 
performance into the new <AppName>_SysInf o .Mon_Log file. The system retains only 
one backup copy of the monitor log files. The format of the report file is give 
below in Table 2 : 



Detailed Description Text (154) : 

where, Time represents the time stamp of the record in the log file; and DiskUsage 
represents the percentage of the file disk usage if STORAGE_TYPE=FLATFILE . Again, 
the data fields are delimited by a comma. It is noted that the database table space 
usage is generally not available to the application user, such that only the system 
administrator has the privilege to view it. As such, the monitor does not perform 
monitoring for the database table space usage. 

Detailed Description Text (157) : 

The Monitor Object is instantiated by the DX_SysConf igOb j ect instance or by calling 
the static method DX_Monitor :: Instance ( ) directly. There is only one DX_Monitor 
thread running per executable component. The monitor thread is spawned whenever the 
MONITOR in the system configuration file is triggered to ON. The monitor thread 
exists until the MONITOR is triggered to OFF. The implementation of the monitor 
impacts three areas. The Queue Manager provides the queue performance data. The 
DX_SysConfigObject provides the configuration change handling and the monitor 
object instantiation. The DX_Monitor Object spawns , or kills the monitor and 
generates the monitor log files or log table in the database , the methods added in 
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the DX_Queue classes are listed below: 
Detailed Description Text (168) : 

A shell/bat script DX__Shutdown is provided to shutd^?^ individual components 
identified by the component name. DX_Shutdown neejis to halt all the threads of 
execution gracefully before shutting down the M^onent . The syntax of the 
DX_Shutdown script is DX_Shutdown <ComponentN^e><Pid> . An implementation example 
is provided as follows. DX_Shutdown script u^es DX_ConfigSet to communicate with 
the component being shutdown. DX_Conf igSeJfer can be used to raise a signal or event 
after adding a parameter to the confi^>file to indicate that an instance of the 
particular component is to shut dowrl^racef ully . The configuration parameter used 
is DX__SHUTDOWN and its value is s^ to the PID of the instance to be shutdown. 

Detailed Description Text (177) : 

Concerning data exchange system security, the basic security control is focused on 
the queue files access or the database tables access. The file access control 
requires the application user to be in a specific user group. The user group should 
be set before the application runs. The database table access control requires the 
application users to have the correct user name and user password. The user name 
and user password may be set in the environment variables or be hard coded in the 
application programs. In one embodiment, all applications share one database user 
account. This user account has privileges to create/update/delete tables in the 
view. 

Detailed Description Text (183) 

A DX_Utils library provides the DX_Mutex/6lass for platform independent mutex 
protection, an example of which is proyided below. The DX_Mutex class does not 
require use of the DX_ThreadControl],^ class. 

Detailed Description Text (187) 
A skeleton main ( ) function is provided to illustrate the system initialization and 
startup procedures required for each component of the data exchange system 
application. This includes operations such as database connection, system resource 
configuration, thread control, etc. In addition, a System Health Monitor Xhread is 
provided which, on a timed interval, polls all system resources to ensuj^ that 
system operation can continue. This thread invokes the system checking operations 
System Configuration Object. The sample code provided below illustra»tes the ease of 
initializing system components and application operations. This san^le is part of 
the DX_Engine executable, which serves as the core of the data ex'change system. 

Detailed Description Text (196) 

A further description of a data exchange system queuing me,trfiodology in accordance 
with one embodiment of the present invention will now be/aescribed. In order to 
provide a clean "buffered API," a queued request appro^h is used. Use of interface 
queues allows the caller of the API to send its reque^ irrespective of whether the 
engine core and another outgoing adapter are running/^ The queue interface approach 
of the instant embodiment also provides a mechanisrt/ for buffering the load that may 
be placed upon a server from multiple clients. It also provides the ability to 
scale the number of database servers that can process any given queue in parallel. 

Detailed Description Text (197) 

As was discussed previously, two types of/priority based queues are used, namely, 
the incoming Receive Queues and the outg.oing Send Queues. Each outgoing adapter 
will have its own outgoing queue so tha't any interface specific translation or 
routing may be performed outside the engine core. Each instance of the DX_Engine 
executable has one or more input queoes, although only one is allowed for file- 
based queues, and one or more outmft queues. An instance of the DX_QueueManager 
class is used as a central proxy /£o all queue access, and will be mutex protected 
and record-lock protected, for file-based implementation, or row lock protected, 
for database implement a tions^^/o prevent data contention. 
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Detailed Description Text (198) : 

Two types of queues are provided, file and database queues, both of which are 
fairly simple implementations that allow for a clean breakup to the API . Priority 
based queuing is provided so that requests of jKxgh importance can be serviced 
quickly. Multiple queues are used to provide/this level of functionality, but the 
implementation is logically transparent toyusers. A user perceives that there is 
only one logic queue with objects of dif^/^ent priority in it. 

Detailed Description Text (199) : 
The file storage or database tables fifer the queue are created at running time and 
deleted by queue administration process. There are iour types of pre-defined 
priority: NONURGENT; NORMAL; URGENT; and INTERACTIVE in order of increasing 
priority. INTERACTIVE is the hio^est priority, which can block any request having 
other priorities. The priority /algorithm ensures that the Dequeue operation always 
returns successfully when the/queue is not empty, prevents starvation of lower 
priority entries, and ensure/ more frequent visits on higher priority queues. The 
priority algorithm is impl^ented on a weighted basis of each priority. 



Detailed Description Text (200) : 
Support for parallel gateways is only available to a dgUfabase queue implementation. 
File-based queue implementations will not guarantee ^s^ngle delivery, i.e., one 
object might be dequeued by multiple process at tb^same time. All parallel access 
should be completely transparent to any partic^^^ting gateway. The only areas of 
common resources between any parallel gatewa^ are the Enqueue and Dequeue 
operations. The design of the Enqueue/Decm^e module ensures that parallel access 
is made possible without any deadlocks yt duplicated queue entries by using the 
database " supplied row-level locking. 



Detailed Description Text (201) : 
Since the external API is limited to the Enque>r€/ Dequeue API, the only limit to 
multiple access is the row-level table lockirfg that the database supports. The file 
based queue mechanism uses simple file rep^d-lock to protect from multiple updates 
to the file from multiple threads. The cytieue access operations for file-based 
implementation are thread-safe, such tmat all the operations are mutex protected. 

Detailed Description Text (202) : 
The Queue Manager public interface makes use of the DX_QueueTransaction object for 
transaction control. The Enqueue ( ), Dequeue { ), Commit ( ), and Rollback ( ) methods 
take pass-in argument of an instance of the DX_QueueTransaction class which belongs 
to a running thread. The transaction object contains an ordered list of operations 
performed in this transaction. For file-based implementations, all operations are 
maintained in buffered memory and are not written into file storage until commit 
time. For database implementations, the^ database provided rol'lback mechanism is 
employed, with each transaction using its own unique run-t>me database context. 

Detailed Description Text (212) : 
DX_FileQueue class contains four child queues for e^h priority. Besides the queue 
operation interface and transaction interface, the/ algorithm of priority handling 
is also implemented in this class. The priority aagorithm is implemented inside the 
Dequeue method. The DX IndexObject argument of Wcib Dequeue methods is used for 
transaction control. At running time, Dequeue^operations fill in corresponding 
fields in DX IndexOb j ect , which is a component: of DX_QueueOperation object. An 
implementation example is given as follows:/^ 



Detailed Description Text (216) : 

Each queue is stored into two categories of files. Each Common Object will be 
stored as a single file, named by its OID. These files will be evenly distributed, 
on the modula of 256, into different sub-directories for purposes of even file 
distribution and performance. These files are generated when the object is 
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serialized. The index of each Common Object is stored in a series of indexed files, 
indexed from 0 to 9999, which is the physical and persistent storage for the logic 
queue. Each file may contain up to 100 index records. The order of the index record 
is defined by the offset of that record to the beginning of the file. 

Detailed Description Text (218) : 

The enqueue operation appends a record at the end of the n'^west file. The dequeue 
operation attempts to find a valid record from the inte^al memory buffer. If one 
is not found, the dequeue operation will then read 03>e index object from file into 
the memory buffer. A status field is used to determine the validity of the record. 
An object can be marked as follows: NEW_OBJECT (object is enqueued but not 
committed yet); ENQUEUE D_OBJECT (object is encm^ed and committed); NORMAL_OBJECT 
(valid object in the queue storage or a the ^Tject was rolled back in the memory 
buffer) ; ACTIVE_OBJECT (object is read from/file into memory buffer and being 
processed) ; or DELETED_OBJECT (object has/been processed after it is dequeued or it 
was marked as so in the file) . The objecxc in the file storage will only be labeled 
DELETED_OBJECT after the transaction i.z committed. An implementation example is 
given as follows: / 

Detailed Description Text (223) : / 

DX_DBQueue is the database -based Ainpl omenta tion of the DX_Queue interface. Its 
instance is mapped to a single rable per queue at run-time. The order of the 
records is determined by the er^^ueue time stamp. All dequeue operations are sorted 
by priority and enqueue time /tamp. An illustrative example of a DX_DBQueue 
implementation is provided a/ follows: 

Detailed Description Text (225) : 

The DX _IndexObiect class is important for all the queue operations. It is used to 
^niquely identify the location at which a Common Object is stored, and is further 
\jused for internal routing of all queue requests. The DX IndexObject class is member 
' of the DX_QueueOb ject class and DX_QueueOperation class. Its members include queue 

name, queue priority, storage type, file handle, file index^ ^record offset, and 

record sequence. An illustrative example of a DX IndexObjeot^ implementation is 

provided as follows: y/ 

Detailed Description Text (227) : X 

The invocation of the Enqueue ( ) and Dequeue ( ) API/is effected by sending a 
request to the Queue Manager Object. In response l2<o a request, the Queue Manager 
Object locates the correct queue and populates tfte operations to that queue object. 
When Enqueue ( ) is invoked, the object is plac;^ into a buffer list and will not be 
collapsed into a data stream until Commit ( ) /Is invoked. Until the commit time, the 
DX IndexObject attribute of the DX_QueueOpei?ation object retains the real meaning, 
which may be used in connection with a roMback operation if the commit operation 
is not successfully executed. For purpose?^ of serialization, if the queue is a 
database, the row-level locking providefa by the database is used. If the queue is a 
file, file access control is used. When a Common Object is serialized at commit 
time, a priority tag is appended tCj/ts private attribute list, such that when the 
Common Object is dequeued, its pricxAty can be easily determined. 

Detailed Description Text (228) : / 

When Dequeue ( ) is invoked, the^^ldest entry with the proper priority is retrieved 
with the marshalled object thei/ being instantiated as a Common Object using the 
Demarshal ( ) method invocation. This mechanism provides database row-locking on 
read events to prevent parallel gateways reading the same queued requests. If the 
queue is file based, record (lock is used. The logic to determine which priority 
queue should be invoked on implemented inside the DX_Queue object. 

Detailed Description Text (230) : 

The Error Queue is needed to provide storage for run-time processing failures. 
Since the entries are stored in a queue with an index to the object that generated 
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the error, the processing logic can decide what further operations should be 
performed. The implementation of Error Queue is as an instance of DX_Queue . Since 
no priority issue is involved in Error Queue, the priority argument of the queue 
operation is relegated to a dummy argument, and only one of the internal child 
queues need be used. 

Detailed Description Text (232) : 

Objects are stored and retrieved from a persistent store in an efficient manner. 
Two types of object storage, termed relational database storage and file storage, 
are implemented for this purpose. The object persistency is implemented using 
Marshal ( ), Demarshal ( ), and DeleteStorage ( ) methods of the DX_CommonOb j ect 
class, where a parameter is passed to indicate stora^-^^ype . A policy for object 
caching and sharing may also be employed. 

Detailed Description Text (233) : 
Since database implementation may vary am^rfg venders and file based persistency is 
needed, the object persistency model ha^^een developed to be independent from any 
database storage technology. This apmr^ach involves collapsing the object into a 
raw binary data stream, and uses va^ous headers to denote any marker and priority 
related information. The headers p/z a Common Object typically include OID and 
priority tag information. Table y4 provide below illustrates a how a Common Object 
may be stored in a typical data fcase . 

Detailed Description Text (234) : 

As stated previously, all database access is hid^n inside the Enqueue ( ) and 
Dequeue ( ) methods of DX_QueueManager and Mars^l { ) , Demarshal ( ) , and 
DeleteStorage ( ) methods of DX_CommonObjecty^n one embodiment, all vendor specific 
access mechanisms may be delivered in a s^ferate set of database enabled libraries. 



Detailed Description Text (238) : 
File-based database access is invoked using the Marshal ( ), Demarshal ( ), and 
DeleteStorage ( ) methods from the Common Object with the output argument set to a 
file. Each object may be stored to a separate file where the filename incorporates 
the object ID. By using the object counter mechanism as a dir-e'ctory name, files can 
be spread evenly across a file system for better access time^ 

Detailed Description Text (240) : 

A transaction object should be created and destroyedySs a local object of a thread. 
If neither Commit ( ) nor Rollback { ) was called whs-n a thread exits, all operations 
executed by this thread are rolled back. For a da«^base implementation, the native 
transaction control mechanism of the database used. For a file implementation, a 
transaction object contains a list recordingy€^r all operations in the current 
transaction. This memory buffer is used to i^uffer all queue operations and will not 
be written into file storage until commit/time. Rollback ( ) removes the operations 
from that memory buffer for operations y*^nat have not been committed,. Since Commit 
( ) might fail, Rollback ( ) also clea)?fs the entries in the queue^^iles and Common 
Object file for those operations tha^ failed at commit time. 




Detailed Description Paragraph Table (2) : 

enum EclassTypes { DX_OBJECT = 0, DX_ATTRIBUTE , DX_LIST/^ DX_MULTIVALUE , DX_INTEGER, 
DX_STRING, DX_STRINGVAL, DX_DATE, DX_TIME, DX_REAL, M^BLOB, DX_BLOBVALUE , 
DX_VERSION, DX_OID_CLASS }; enum EreturnCodes { NOT/FOUND = 0, SUCCESS, FAILED, 
TIME_OUT, ACCESS_DENIED, DUPLICATE_OBJECT, NO_OBJB^T, NO_ATTRIBUTE , 
INVALID_ATTRVAL, INVALID_ARGS , INVALID_OPERATI<^»f; SySTEM_ERROR }; enum 
EstorageTypes { FLATFILE = 0, DATABASE }; eniipr ElistType { PUBLIC = 0, PRIVATE }; 
static const int MAX_NAME_LEN=255 ; static ccmst int MAX_D0TTED_NAMELEN=8 096; static 
const int MAX_MULTI__VAL=255; static const yOit MAX_BLOB_SIZE=2048 ; static const int 
OID_LEN=12 8; static const int MAX_FILE_N^E=256; static const int MAX_PID_LEN=12 ; 
static const int MAX LINE SIZE=100; 
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Detailed Description Paragraph Table (3) : 

class: DX_CommonObject : public DX_CoramonBase { RWDECLARE_COLLECTABLE 
(DX_CommonObject) ; friend class DX_ListOb j ect; friend class DX_FileSubQueue; 
public: virtual . about . DX_CommonObj ect () ; // 

Constructors / / /j 

name==NULL, the name is set to "NOT_SET". //If name is ""or contains a it will 

be set to 

"INVALID NAME" /*********************************************************^ 
DX_CommonObj ect (const char* 

name=0) ; /*********************************************★★★★★★★*★***•*★★★★★** / / /Great 

a copy of an entire DX_CommonOb j ect, //but with it's own unique OID 
value /***************"^**"******************************* 

DX_CommonOb j ect* Clone 

{) ; /************************************************** //All 
AddAttribute and AddPvtAttribute methods take ownership of //the pointers passed in 
to them. Do NOT delete the pointers after //a call to AddAttribute and 
AddPvtAttribute. The pointers will be //deleted when the container DX_CommonOb j ect 
or DX_ListObject is deleted. // //NOTE: When using the following two methods for 
creating a DX_STRING attribute // // AddAttribute ( const char* name, const int type, 
const void* value) // and AddPvtAttribute ( const char* name, const int type, const 
void* value) // // the value is defaulted to be of type const char* and not 
UNICHAR* // Misuse will lead to unexpected 
behavior . /************* 

EreturnCodes AddAttribute (DX_CommonAt tribute* newAttr) ; EreturnCodes AddAttribute 
(DX_ListObject* newAttr) ; EreturnCodes AddAttribute (DX_CommonObj ect* newAttr) ; 
EreturnCodes AddAttribute (const char* name, const int type, const void* value); 
EreturnCodes AddPvtAttribute (DX_CommonAttribute* newAttr); EreturnCodes 
AddPvtAttribute (DX_ListObject* newAttr); EreturnCodes AddPvtAttribute 
(DX_CommonOb ject* newAttr); EreturnCodes AddPvtAttribute (const char* name, const 
int type, const void* 

value) ; /************************************★*★★★★★★★★★★★★★★★★★★★★★★★*★★★ //Delete 
and DeletePvtAttribute will remove the named attribute //from the container 
DX_CommonObject or DX_ListOb j ect and delete the named //attribute's 
pointer /**************** 

EreturnCodes DeleteAttribute (const char* name); EreturnCodes DeletePvtAttribute 
(const char* 

name) ; /************************************★★*★★★★★★★★★★★★★★★★ //RemoveA 
will remove the named attribute from the container //DX_CommonOb j ect or 
DX_ListObject but will not delete the named //attribute's 
pointer /************************************-'^************ 

EreturnCodes RemoveAttribute ( const char* name); EreturnCodes RemovePvtAttribute 
(const char* 

name); /***************************************★★**★*★★★★★ //Do NOT 

delete the pointer that is returned to you, it still is owned by //the container 
DX_CommonObject or DX_ListOb j ect . You CAN use the any of //the attribute class 
methods for the 

pointer . /**************************************★★*★*★****★★★★★*★★★★★★*★ void* 
GetAttribute (const char* name); void* GetPvtAttribute ( const char* name); void 
PrintContents ( ) ; //The caller of Demarshal is responsible for object's memory 
allocation static DX_CommonOb j ect* Demarshal ( char* ObjOid, int type, int 
Contextlndex) ; EreturnCodes Marshal (int type, int Contextlndex) ; static 
EreturnCodes DeleteStorage ( const char* oidVal, int type, int Contextlndex); //The 
caller of GetOID is responsible for deleting the memory of the returned char* char* 
GetOIDO; EPriorityCode GetPriority ( ) ; protected: void* Find(const char* name); 
static EreturnCodes RestorePersistentObj ect (const char* oidVal); static 
EreturnCodes DeletePersistentObj ect (const char* oidVal, int type); private: //Data 
Members DX_ListOb j ect* PrivateList; DX_ListOb j ect* PublicList; static void Delete 
(RWDlistCollectables* list); static int Copy (RWDlistCollectables* dest, const 
RWDlistCollectables *src) ; static EreturnCodes CopyPersistentObject (char* 
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filename); static EreturnCodes CopyFile ( char* filename, char* copyfilename) ; void 
saveGuts (RWFile& file) const; void saveGuts (RWvostream& stream) const; void 
restoreGuts (RWFile& file); void restoreGuts (RWvistream& stream); const int check() 
const; DX_Boolean updateListOids {DX_ListOb j ect* Plist, DX_OID *Poid) ; DX_Boolean 
updateObjectOids (DX_CommonOb ject* Pobj, DX_OID *Poid) ; DX_Boolean ValidateNaming 
(const char* name); #ifdefDX DATABASE EreturnCodes InsertlntoTable (char* filename, 
int Contextlndex) ; static EreturnCodes RetrieveFromTable (char* filename, char* oid, 
int Contextlndex); EreturnCodes UpdateTable (char* filename, int Contextlndex); 
#endif //use to cal . the number of bytes needed to store an object using RWFile 
RWspace binaryStoreSize ( ) const;); }; 

Detailed Description Paragraph Table (34) : 

class: DX_QueueLogMgr { public: // create an instance of the object by calling the 
constructor // delete using Deletelnstance ( ) static DX_QueueLogMgr* Instance (char* 
ComponentName=0) ; // delete the object static void Deletelnstance ( ); // Checks if 
the QueueStatusList has an entry // for the particular queue and if so checks // if 
the entry indicates whether the // queue monitoring is on or off and logs the // 
QueueObject accordingly static void DumpQLog (EQueueOperation op, char* queueName, 
DX_QueueOb ject* qo) ; // if you want to monitor a queue, an entry in // the queue 
status list should be created first // by giving the queue name and the pid. The 
function // reads the . reg file and initializes the entry // accordingly. 
EreturnCodes InsertQueueStatusList (char* QName, int pid); // if queue monitor 
changed the queue registration file, reset the // object, read the reg file and 
update the queueStatusList ; EreturnCodes Reconf igQueueStatusList ( ); private: 
DX_Mutex* listLock; static DX_QueueLogMgr* instance; char ComponentName 
[M7\X_NAME_LEN] ; char QlogDir [MAX_FILE_NAME ] ; DX_QueueLogMgr (char* 

inComponentName=0, char* qlogdir=0) ; virtual . about . DX_QueueLogMgr ( ) ; EreturnCodes 
DeleteFromRegFiles (char* ComponentName, int pid); DX_INDICATOR GetStatusFromRegFile 
(char* regFileName, int& regFileExists) ; char* GetQRegFileName ( char* QName); 
EreturnCodes FindQueueLogStatusInf o (char* inQName, DX_QueueLogStatusInf o** copy) ; 
RWDlistCollectables *queueStatusList; ); class DX_QueueLogStatusInf o : public 
RWCollectable { friend class DX_QueueLogMgr; private: char qName [MAX_NAME_LEN] ; 
DX_INDICATOR qLogStatus; char qLogFileName [MAX_FILE_NAME] ; RWDECLARE_COLLECTABLE 
(DX_QueueLogStatusInf o) ; DX_QueueLogStatusInf o ( ){ }; // During construction if 
inQLogStatus is ON // open the logStream for QName. qlog in directory 
DX_HOME/DX_QLOG DX_QueueLogS tatusinf o ( char* inQName, DX_INDICATOR inQLogStatus, 
char* qlogdir); // close all the streams which are 

open . about .DX_QueueLogStatusInfo ( ); char* Ge t QName ( ); DX_INDICATOR GetQLogStatus 
( ); char* GetQLogFileName ( ); // if set to on, open stream, if set to off close 

the stream EreturnCodes SetQLogStatus (DX_INDICATOR inStat) ; }; #define DX_QLOG 
(QueueOp, QueueName, qo) DX_QueueLogMgr : : .backslash. DumpQLog (QueueOp, QueueName, qo) ; 

Detailed Description Paragraph Table (42) : 

enum EstorageTypes { FLATFILE = 0, DATABASE ); enum EQueueOperation { ENQUEUE = 0, 
DEQUEUE ); static const int NUM_PRIORITIES = 4; enum EPriorityCode { NONURGENT = 0, 
NORMAL, URGENT, INTERACTIVE }; 

Detailed Description Paragraph Table (43) : 

class: DX_QueueManager { friend class DX_QueueTransaction; friend class DX_DBQueue; 
friend class DX_Monitor; public: static DX_QueueManager* Instance (const char* 
ProcessName, EstorageTypes type); static void Deletelnstance ( ); static 
DX_QueueManager* Getlnstance 

( ) . / / /Queue 

operation 

interface /*************************************+*****************★*★★★* / 

label and comment arguments will be used for Queue Administration Purpose. //So 

queue administration GUI will also see the name and comment of each CO in 

the //queue. They can be type of UTF-8 encoded string, 7-bit ASCII string or wide 

string. //User should not delete pointer to DX_CommonOb ject after call 

Enqueue /**************************************************★ 
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EreturnCodes Enqueue (const char* qName, DX_CominonObj ect &co, DX_QueueTransaction 
&transaction, const char* oLabel, const char* comment, EPriorityCode priority = 
NORMAL); EreturnCodes Enqueue (const char* qName, DX_CommonOb j ect &co, 
DX_QueueTransaction itransaction, const UNICHTU^* oLabel, const UNICHAR* comment, 
EPriorityCode priority = 

NORMAL) ; / / /Caller 

should free non-NULL pointer to DX_CommonOb j ect //Return SUCCESS if Dequeue 
returned a common object //Return FAILED if Dequeue returned a NULL common object 
pointer /*********************************************************** 
EreturnCodes Dequeue (const char* qName, DX_CommonOb j ect* &C0 DX_QueueTransaction 
&transaction) ; EreturnCodes Dequeue (const char* qName, const char* objID, const 
char* obj Label, DX_CommonOb j ect* &co, DX_QueueTransaction 

& transaction ) ; /****************************************★*★*********★**★**★**★★★/ j j 

caller of GetCursor is responsible for deleting //returned DX IndexObject* 
pointer . /****************************************★*****★★★★★★★★★★★★★★*★ 

DX IndexObject* GetCursor (const char* qName, EPriorityCode priority = 

INTERACTIVE ) ; /******************************★*****★**★★★*★★★★★*★★★★ //W 
set the cursor to the EPriorityCode passed 

in /******************** + EreturnCodes 
ResetCursor (DX IndexObject &cursor, EPriorityCode priority = 

INTERACT I VE ) ; /********************************★***★★★★*★★★*★****★★★*★* //T 
always is a non-null DX_QueueList returned //Caller should delete 

DX_QueueObjectList returned // //NOTE: DX_QueueList may be empty if no entries were 
found // //USAGE: //GetQueueView (DX_QueueOb j ectList* &list DX IndexObject 
&QViewCursor, // int size = 0) //will return #entries =< size for EPriorityCode of 
QViewCursor and ALL lower priorities // //GetQueueView (DX_QueueObjectList* &list, 
EPriorityCode priority, // DX IndexObject &QViewCursor , int size = 0) //will return 
#entries =< size for EPriorityCode of priority, QViewCursor is updated to //reflect 
position of last retrieved 

entry. /************************************v*r********-A: ★★★★★★★ 

EreturnCodes GetQueueView (DX_QueueObj ectList* &list, DX IndexObject &QViewCursor, 
int size = 0; EreturnCodes GetQueueView (DX_QueueObj ectList* &list, EPriorityCode 
priority, DX IndexObject &QViewCursor , int size = 

0) ; /***************************★★★★★**★★★★★*★★★★★★★*★★★★★★★★★ //Caller 
should free char** returned 

twice /**************************************************************^-jt char** 
GetManagedQueueNames (int& number); char** GetAllQueueNames ( int& number); private: 
static DX_QueueManager* instance; char* owner; EstorageTypes Implementation; char* 
FileDBDirectory; RWGDlist (DX_Queue) QueueList; DX_Mutex* mutex; DX_QueueManager 
(const char* processID, EstorageTypes type, const char* FileDBDir) ; 
. about . DX_QueueManager ( ); //Extended transaction support interface EreturnCodes 
Commit (DX_QueueTransaction &transaction) ; EreturnCodes Rollback (DX_QueueTransaction 
&transaction) ; //Queue administration interface EreturnCodes DeleteQueue (const 
char* qName); EreturnCodes FlushQueue ( const char* qName); EreturnCodes FlushQueue 
(const char* qName, EPriorityCode priority); EreturnCodes RemoveFromQueue 
(DX_QueueObject *object) ; //Performance monitor interface //the memory of 
pNumOfMsgProcessed, pAvgMsgCacheTime, pAvgMsgProcessTime //should be allocated 
before invoking this method. EreturnCodes GetQueuePerf ormance (char * inputQName, 
long *pNumOfMsgProcessed, double *pAvgMsgCacheTime, double *pAvgMsgProcessTime, 
DX_Boolean resetFlag = TRUE); void ResetAll (const char *qNameList) ; EreturnCodes 
GetDBTableSpaceUsage (float &usage) ; //Internal use DX_Queue* FindQueue (const char* 
qName); DX_Queue* CreateQueue (const char* qName); ); 

Detailed Description Paragraph Table (44) : 

class: DX_Queue { friend class DX_QueueManager; friend DX_Boolean IsQueueEqual 
(const DX_Queue* queue, const void* value); protected: virtual .about. DX_Queue ( ); 
virtual EreturnCodes Enqueue (DX_CommonObj ect & co, const char* Processid, const 
char* label, const char* comment, DX_QueueTransaction& transact, EPriorityCode 
pCode) = 0; virtual DX_CommonOb ject* Dequeue (DX_QueueTransaction& transact) = 0; 
virtual DX_CommonOb j ect* Dequeue (DX_QueueTransaction& transact, const char* 
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ObjectID, const char* ObjectLabel) = 0; //Only DX_FileQueue need to implemented the 
following two methods virtual EreturnCodes Commit (DX_QueueOperation& oper) {return 
FAILED;} virtual EreturnCodes CompleteCommit (DX_QueueOpe rations oper) {return 
FAILED;} virtual EreturnCodes Rollback (DX_QueueOperation& oper) {return FAILED;) 
const char* GetQueueName ( ) const; virtual EreturnCodes DestroyStorage ( ) = 0; 
virtual EreturnCodes Flush (EPriorityCode priority) = 0; virtual EreturnCodes 
RemoveObject (DX_QueueObject* qOb j ) = 0; virtual EreturnCodes GotoBeginning 
(EPriorityCode priority, DX IndexObject &cursor) ~ 0; virtual EreturnCodes 
GetQueueView (EPriorityCode priority, DX IndexObject &cursor, DX_QueueOb j ectList* 
&list, int size) = 0; //performance monitor virtual void GetQueuePerf ormance ( long 
*pNumObjectProcessed, double *pAvgMsgCacheTime, double *pAvgMsgProcessTime ) = 0; 
virtual void Reset ( ) = 0; //We should not have instance of this class DX_Queue 
(const char* qName) ; in line void SetWeightRootsAndVisitedFlags ( ) { roots 
[NONURGENT] = O.Of; roots [NORMAL] = 0.6f; roots [URGENT] = 0.8f; roots [ INTERACTIVE ] 
= l.Of; //will always block other priorities VisitedFlags [NONURGENT] = 0x01; 
VisitedFlags [NORMTVL] = 0x02; VisitedFlags [URGENT] = 0x04; VisitedFlags [ INTERACTIVE ] 
= 0x08; } //Because these members should be seen by the derived classes, //we keep 
them as protected, float roots [NUM_PRIORITIES] ; unsigned char VisitedFlags 
[NUM_PRIORITIES] ; float weights [ NUM_PRIORITIES ] ; char *QueueName; ); 

Detailed Description Paragraph Table (45) : 

class: DX_FileQueue : public DX_Queue { friend class DX_QueueManager; private: 
DX_FileQueue (const char* qName, const char* FileDBDir) ; . about . DX_FileQueue ( ); 
EreturnCodes Enqueue (DX_CommonObject& co, const char* Processid, const char* label, 
const char* comment, DX_QueueTransaction& transact, EPriorityCode pCode) ; 
DX_CommonObject* Dequeue (DX_QueueTransaction& transact) ; DX_CommonOb j ect* Dequeue 

(DX_QueueTransaction& transact, const char* ObjectID, const char* ObjectLabel); 
EreturnCodes Commit (DX_QueueOperation& oper); EreturnCodes CompleteCommit 

(DX_QueueOperation& oper); EreturnCodes Rollback ( DX_QueueOperation& oper); 
EreturnCodes DestroyStorage ( ); EreturnCodes Flush (EPriorityCode priority); 
EreturnCodes RemoveObject {DX_QueueObj ect* qOb j ) ; EreturnCodes GotoBeginning 

(EPriorityCode priority, DX IndexObject &cursor) ; EreturnCodes GetQueueView 

(EPriorityCode priority, DX IndexObject &cursor, DX_QueueObj ectList* &list, int 
size); //used for the performance monitor void GetQueuePerf ormance (long 
*numOfMsgProcessed, double *avgMsgCacheTime, double *avgMsgProcessTime) ; void Reset 

( ); private: DX_FileSubQueue* subqueues [NUM_PRIORITIES ] ; DX_Mutex* WeightMutex; 
DX_Mutex* SubQueueMutex [NUM_PRIORITIES] ; }; 

Detailed Description Paragraph Table (46) : 

class: DX_FileSubQueue { friend class DX_FiIeQueue; friend class DX_QueueManager ; 
private: DX_FileSubQueue ( const char* qName, EPriorityCode pCode, const char* 
FileDBDir); . about . DX_FileSubQueue ( ); EreturnCodes Enqueue ( DX_CommonObj ect& co, 
const char* Processid, const char* label, const char* comment); DX_CommonObj ect* 
Dequeue (DX IndexObject& io); DX_CommonOb ject* Dequeue (DX IndexObject& io, const 
char* ObjectID, const char* ObjectLabel); EreturnCodes Commit (DX_QueueOperation& 
oper); EreturnCodes CompleteCommit (DX_QueueOperat ion & oper); EreturnCodes Rollback 

(DX_QueueOperation& oper); EreturnCodes DestroyStorage ( ); EreturnCodes Flush ( ); 
EreturnCodes RemoveObject (DX_QueueObj ect* qOb j ) ; EreturnCodes GotoBeginning 

(DX IndexObject& cursor); EreturnCodes GetQueueView (DX IndexObj ect &cursor, 
DX_QueueObj ectList* &list, int size); //used by the performance monitor long 
GetNumOfMsgProcessed ( ); double GetTotalMsgCacheTime ( ); double 

GetTotalMsgProcessTime ( ); void Reset ( ); private: char* QueueName; EPriorityCode 
Priority; char* QueueFileName; char* IndexDirectory ; int startFilelndex; int 
endFilelndex; //These two fields are used for Dequeue operation and always go 
forward int currentFilelndex; int currentRecordlndex; int lastRecordlndex; 
DX_QueueObj ectList BufferList; ////////////////////////// //Internal use 
only ////////////////////////// EreturnCodes EnqueueCommit (DX_QueueOperation 
&oper) ; EreturnCodes DequeueCommit (const char* old, const DX IndexOb j ect* io) ; 
EreturnCodes CompleteEnqueueCommit (DX_QueueOperation &oper) ; EreturnCodes 
CompleteDequeueCommit (const char* oid, const DX IndexObject* io) ; EreturnCodes 
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EnqueueRollback (const char* oid, const DX IndexObj ect* io) ; EreturnCodes 
DequeueRollback (const char* oid, const DX IndexObj ect* io) ; EreturnCodes 
TryRecycleFile (int f Index) ; void TryRecycleQueue ( ); char* GetFileName ( int f Index) ; 
int OpenFile(int whichFile) ; EreturnCodes CreatEndFile ( ); void UpdatelndexFile ( ); 
void UpdateFilelndex ( ); EreturnCodes ExpandQueue ( ); EreturnCodes MarkOb j ectlnFile 
(const DX IndexObject* iOb j , EQueueOb jectStatus status); //Unix does not have low- 
level eof 10 function available int IsEOF{int fd) ; //used by performance monitor 
double totalMsgCacheTime; double totalMsgProcessTime; long numOfMsgCommited; void 
SetDequeueTime (DX_QueueOb j ect *qo) ; void SetEnqueueTime ( DX_QueueOb ject *qo) ; void 
CompleteCommitCalculation (DX_QueueOb ject *qo) ; }; 

Detailed Description Paragraph Table (47) : 

class: DX_DBQueue : public DX_Queue { friend class DX_QueueManager; private: 
DX_DBQueue (const char* qName) ; . about . DX_DBQueue { ); EreturnCodes Enqueue 

(DX_CommonObject& co, const char* ProcessId, const char* label, const char* 
comment, DX_QueueTransaction& transaction, EPriorityCode priority) ; 
DX_CommonObj ect* Dequeue (DX_QueueTransaction &) ; DX_CommonOb j ect* Dequeue 

(DX_QueueTransaction& transaction, int priority); DX_CommonOb j ect* Dequeue 

(DX_QueueTransaction& transaction, const char* ObjectID, const char* 
ObjectLabel) ; //Virtual methods inherited from DX_Queue and NOT USED EreturnCodes 
Commit (DX_QueueOperation& oper) {return FAILED;} EreturnCodes CompleteCommit 

(DX_QueueOperation& oper) (return FAILED;} EreturnCodes Rollback (DX_QueueOperation& 
oper) (return FAILED;} static EreturnCodes Commit (DX_QueueTransaction& 
transaction); static EreturnCodes Rollback (DX_QueueTransaction& transaction); 
static EreturnCodes CreateTable (int DBcontextId, const char* qName); EreturnCodes 
DestroyStorage ( ); EreturnCodes Flush (EPriorityCode priority); EreturnCodes 
RemoveObj ect (DX_QueueOb ject* qOb j ) ; EreturnCodes GotoBeginning (EPriorityCode 
priority, DX _IndexObi ect &cursor) { return SUCCESS;} EreturnCodes GetQueueView 

(EPriorityCode priority, DX IndexObj ect &cursor, DX_QueueOb j ectList* &list, int 
size); //used for the performance monitor void GetQueuePer f ormance (long 
*NumOfMsgProcessed, double *avgMsgCacheTime, double *avgMsgProcessTime) ; void Reset 

( ); static EreturnCodes GetTableSpaceUsage ( float &usage) ; static char** 
GetAllQueueNames (int& number); //Data member DX_Mutex* WeightMutex; //used by 
performance monitor long * numOfMsgCommited; double * totalMsgCacheTime; double 
*totalMsgProcessTime; static void CommitCalculations (DX_QueueTransaction 
&transaction) ; }; 

Detailed Description Paragraph Table (48) : 

class: DX IndexObj ect { friend class DX_QueueOb j ect ; friend class 

DX_QueueOperation; friend class DX_FileSubQueue; friend class DX_FileQueue; friend 
class DX_DBQueue; friend class DX_QueueManager ; public: //Because GetQueueView 
needs an instance of DX _IndexObi ect as cursor //and user should be able free the 
instance after use . about . DX _IndexObi ect ( ); private: DX ^IndexObj ect (EstoraqeTypes 
type); DX IndexObj ect (EstorageTypes type, const char *qName, EPriorityCode 
priority); DX IndexObj ect ( const DX IndexOb j ect & inputIO) ; DX IndexObj ect & operator= 
(const DX IndexObj ect& inputIO) ; in line EstorageTypes GetStorageType ( ) const 
{ return StorageType; } in line const int GetFileHandle ( ) const ( return 
FileHandle; } in line const char* GetQueueName ( ) const { return QueueName; ) in 
line EPriorityCode GetPriority( ) const { return Priority; } in line int 
GetFilelndex ( ) const { return Filelndex; } in line long GetRecordOf f set ( ) const 
{ return RecordOf f set ; } in line long GetTimeStamp ( ) const { return TimeStamp; ) 
EreturnCodes SetFileHandle ( int fh) ; EreturnCodes SetQueueName (const char* qName); 
EreturnCodes SetPriority (EPriorityCode priority); EreturnCodes SetRecordOff set (long 
rOffset); EreturnCodes SetFilelndex ( int f Index) ; EreturnCodes SetTimeS tamp (long 
tm) ; private: char* QueueName; EPriorityCode Priority; EstorageTypes StorageType; 
int FileHandle; //handle to a file already opened int Filelndex; long RecordOf f set ; 
long TimeStamp; //enqueue time ); 

Other Reference Publication (23) : 

Product Literature, "SAIC The Vision," http: //www. saic. com/ teleco m/index , html, 4 
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pgs . (Jan. 1998) . 

Other Reference Publication (26) : 

Product Literature, "MQSeries Business Partners Index, " 

http : //www. software , ibm. com/ts/mqseries/partners/partner .html, 1 pg. (Feb. 1998). 



I. A method of transporting data, comprising: receiving a data stream from each of 
a plurality of source applications, each of the data^treams comprising 
informational content and having a technology dependent form associated with a 
source protocol; converting the data streams tpom the technology dependent forms to 
technology independent forms not associated with the respective source protocols 
and not associated with respective destina^on protocols of one or more destination 
applications; identifying the one or morgr destination applications; transporting 
the data streams having the technolog y/and ependent forms; transforming the data 
streams from the technolog y independ^t forms to technology dependent forms 
associated with the respective destdTnation protocols of the one or more of the 
destination applications; and trarl^mitting all or a portion of the data streams 
having the technology dependent yrorms to the one or more of the destination 
applications. / 

10. A method of transporting data, comprising: receiving, frpirr a source 
application, data comprising informational content in a t^jefmology dependent form 
associated with a source protocol; converting the data £<^m the technology 
dependent form associated with the source applicationXto a technology independent 
form not associated with the source protocol and myf associated with respective 
destination protocols of one or more destination/applications; identifying the one 
or more destination applications; transporting/the data having the technology 
independent form; transforming the data frorp/che technology independent form to a 
technology dependent form associated with yuie respective destination protocols of 
the one or more of the destination appli^tions; and transmitting all qr'^a portion 
of the data in the technology dependent ! form to the one or more of the destination 
applications. / 

II. The method of claim 10, further comprising processing the d^a in the 
technology indepen dent form. / 

28. A system for transporting data among applications, compxising: an input data 
adapter comprising an input interface and an input data converter, the input 
interface receiving an input 'data stream comprising inf<^rmational content and 
having a technology dependent form associated with a .j^urce protocol of a source 
application, the input data converter converting the input data stream having the 
technology dependent form to input data having a technology independent form not 
associated with the source protocol and not associated with a plurality of 
destination applications; a processor communic^ively coupled to the input adapter 
and coordinating the input data having the t^hnology independent form, the 
processor coordinating transmission of all yor a portion of the input data to the 
plurality of destination applications; an^a plurality of output adapters each 
communicatively coupled to the processoi/and a respective one of the plurality of 
destination applications, each of the ^utput adapters comprising an output data 
converter that converts the input dat4 having the technology independent form to an 
output data stream having a technology dependent form associated with a destination 
protocol compatible with a respectwe destination application, and each of the 
output adapters further comprising^ an output interface that transmits the output 
data stream to the respective desuination application. 

30. The system of claim 28, wherein each of the output data adapters implements 
logic for processing the input data having the technology independent form. 



CLAIMS : 




Record Display Form 




/ 

Page 14 of 15 



34. The system of claim 2 8, wherein the processor is coupled to a reoeive queue and 
a plurality of send queues, the receive queue receiving the input da/ca having the 
technology independent form from the input data adapter and the processor 
coordinating transmission of all or a portion of the input data having the 
technology independent form to one or more of the send queues. / 

35. The system of claim 34, wherein the processor communicates /ontrol signals to 
the send queues to coordinate transmission of all or a portion /of the input data 
having the technology independent form to one or more of the ooitput data adapters. 

36. The system of claim 35, wherein processor coordinates transmission of the input 
data having the technology independent form to one or more of the output data 
adapters in an asynchronous or pseudo-synchronous manner. / 

38. A system for transporting data among applications, comprising: a plurality of 
input data adapters each comprising an Input interface and an input data converter, 
each of the input interfaces receiving an input data stream comprising 
informational content and having a technology dependent/ form associated with a 
source protocol of a respective source application, tKe input data converters 
converting the input data streams having technology dependent forms to input data 
streams having technology independent forms not assoAated with the respective 
source protocols and not associated with a plurality of destination applications; a 
processor communicatively coupled to the input adafj^ters and coordinating the input 
data streams having the technology independent form, the processor coordinating 
transmission of all or a portion of the input data streams having .the technology 
independent form to the plurality of destination iapplications; and a plurality of 
output adapters each communicatively coupled to the processor and a respective one 
of the plurality of destination applications, each of the output adapters 
comprising an output data converter that conver*ts a respective input data stream 
having the technology independent form to an output data stream having a technology 
dependent form associated with a destination pprotocol compatible with a respective 
destination application, and further comprising an output interface that transmits 
the output data stream to the respective destination application. 

42. The system of claim 38, wherein the processor is coupled to a receive queue and 
a plurality of send queues, the receive queue receiving the input data streams from 
the input data adapters and the processor cocrdinating transmission of all or a 
portion of the input data streams having technology independent forms to the send 
queues . | 

43. The system of claim 42, wherein the processor communicates control signals to 
the send queues to coordinate transmission /of the input data streams having 
technology independent forms to one or more of the output data adapters in an 
asynchronous or pseudo-synchronous manner/ 

44. A computer readable medium tangibly ambodying a program executable for 
transporting data, comprising: receiving^ from a source application, data 
comprising informational content in a technology dependent form associated with a 
source protocol; converting the data tjom the technology dependent form associated 
with the source application to a techr^Dlogy independent form not associated with 
the source protocol and not associated with destination protocols associated with 
one or more destination applications, y identifying the one or more of the 
destination applications; transporting the data having the technology independent 
form; transforming the data from thJ technology independent form to a technology 
dependent form comprising a destinauion protocol associated with each of the one or 
more of the destination applications ;Vand transmitting all or a portion of the data 
in the technology dependent form to the one or more of the destination 
applications . 



51. A system for transporting data, comprising: means for receiving data comprising 
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informational content in a technology dependent form associated with a so 
protocol from a source application; means for converting t-hfe data from the 
technology dependent form to a technology independent Ufrm not associated wit 
source protocol and not associated with destination^pTrotocols associated with 6 
or more destination applications; means for iden^i^fying the one or more destinati 
applications; means for transporting the data having the technology independent 
form; means for transforming the data from Ufe technology independent form to a 
technology dependent form comprising a des>txnation protocol associated with each of 
the one or more of the destination applications; and means for transmitting all or 
a portion of the data in the technolog^ dependent form to the one or more of the 
destination applications. 
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Detailed Description Text (76) : 

In general, each Common Object is given a unique Object Identifier or OID so that 
any child or related objects can be associated with each other. All objects created 
as a result of this original OID require that this initial OID be stored as part of 
the object, regardless of whether the new object is a direct child object or 
whether the original object still exists. If the original OID were not stored, it 
would not be possible to correlate response objects with the initial request 
object. The OID value is automatically set during instantiation. Parent OID values 

updated automatically when AddAttribute ( ) is invoked, including all Common 
Objects that are contained within a ListObject. 

Detailed Description Text (112): 

When initiated, a component creates an instance of a System Configuration Object 
(DX_SysConf igObject ) that stores the current parameter settings. The component also 
registers for a Signal/Event so that it is informed of changes to the configuration 
using the dynamic configuration command line interface/web interface. When a user 
wants to change the run time parameters of a component (identified by the process 
ID and the machine on which it is running), a signal/event is sent to the component 
to update its configuration. A signal/event handier invokes the Reconf igParameters 
( ) method on the DX_SysConf igObject , which takes care of reconfiguring the various 
controller objects, such as DX_TraceLogOb ject, DX_QueueManager , and 
DX_ThreadCont roller for example. The System Configuration object, 
DX_SysConf igObject, is a singleton object that initializes and controls the 
configuration of a component in the data exchange system, such as logging/tracing 
levels, thread controller, queuing, and performance monitoring. A singleton object, 
as understood in the art, refers to a C+-H nomenclature meaning that only a single 
instance of the class may exist within a single executable. A singleton object is 
most commonly used when controlling system wide resources. 

Detailed Description Text (155) : 

Changes in the run-time monitor configuration are handled through the system 
configuration utility. The System Configuration Object contains an instance of 
Monitor Object which is initialized with the monitor configuration parameter values 
specified in the System Configuration file and saves them as configuration member 
data. When the user modifies the Monitor Configuration parameters at run time, 
typically be use of the deconfigset command, a signal is sent to the component 
which calls the method Reconf igParameters ( ) on the System Configuration Object to 
re-initialize the parameters. This method, in turn, calls reconf igparameters ( ) on 
the Monitor Object and updates the:^ configuration member data. The monitor thread 
reads the configuration member data when it becomes active in the next time 
interval. As such, the monitor configuration parameters are modifiable at run-time. 

Detailed Description Text (173) : 

The DX_QMonitor utility informs the change in the audit logging status of a queue 
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to all the processes using the Queue by updating the registration file and raising 
an event/signal to inform all the components to update their DX_QueueLogMgr 
objects. This command is also responsible for cleaning up entries in the 

A registration file corresponding to components that died without cleaning up the 
-J registration file. Whenever an Enqueue or Dequeue operation is committed, a check 
is made on the DX_QueueLogMgr to see if audit logging is ON or OFF and information 
is logged in case it is ON. When an instance is terminating, the destructor of 
DX_QueueLogMgr should update all the registration files in which it has created an 
entry. An implementation example is provided as follows: 

Detailed Description Text (177) : 

Concerning data exchange system security, the basic security control is focused on 
the queue files access or the database tables access. The file access control 
requires the application user to be in a specific user group. The user group should 
be set before the application runs. The database table access control requires the 
application users to have the correct user name and user password. The user name 
and user password may be set in the environment variables or be hard coded in the 
application programs. In one embodiment, all applications share one database user 
account. This user account has privileges to create /update /delete tables in the 
view. 

Detailed Description Text (201) : 

Since the external API is limited to the Enqueue/Dequeue API, the only limit to 
multiple access is the row-level table locking that the database supports. The file 
based queue mechanism uses simple file record-lock to protect from multiple updates 
to the file from multiple threads. The queue access operations for file-based 
implementation are thread-safe, such that all the operations are mutex protected. 

Detailed Description Paragraph Table (3) : 

class: DX_CommonOb ject : public DX_CommonBase { RWDECIiARE_COLLECTABLE 
(DX_CommonObject) ; friend class DX_ListOb j ect; friend class DX_FileSubQueue; 
public: virtual . about . DX_CommonObj ect 0 ; // 

Constructors /*******************************"^***************** ******* / / /j 

name==NULL, the name is set to "NOT_SET". //If name is ""or contains a "." it will 
be set to 

" I NVAL I D NAME " /***********************************************************■****■**/ 
DX_CommonObj ect (const char* 

name=0 ) ; /*****************************************************************/ / /Creat 
a copy of an entire DX_CommonOb j ect, //but with it*s own unique OID 
value /*****************************************************************/ 
DX_CommonObject* Clone 

AddAttribute and Add Pvt At tribute methods take ownership of //the pointers passed in 
to them. Do NOT delete the pointers after //a call to AddAttribute and 
AddPvtAttribute . The pointers will be //deleted when the container DX_CommonOb j ect 
or DX_ListObject is deleted. // //NOTE: When using the following two methods for 
creating a DX_STRING attribute // // AddAttribute (const char* name, const int type, 
const void* value) // and AddPvtAttribute ( const char* name, const int type, const 
void* value) // // the value is defaulted to be of type const char* and not 
UNICHAR* // Misuse will lead to unexpected 

behavior . /*****************************************************************/ 
EreturnCodes AddAttribute (DX_CommonAt tribute* newAttr) ; EreturnCodes AddAttribute 

(DX_ListOb ject* newAttr) ; EreturnCodes AddAttribute (DX_CommonObj ect* newAttr) ; 
EreturnCodes AddAttribute ( const char* name, const int type, const void* value); 
EreturnCodes AddPvtAttribute (DX_CommonAt tribute* newAttr); EreturnCodes 
AddPvtAttribute (DX_ListOb ject* newAttr); EreturnCodes AddPvtAttribute 

(DX_CommonObject* newAttr); EreturnCodes AddPvtAttribute (const char* name, const 
int type, const void* 

value) ; /*****************************************************************/ //Delete 
and DeletePvtAttribute will remove the named attribute //from the container 
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DX_CommonObject or DX_ListObj ect and delete the named //attribute's 
pQj^j^^g2: 

EreturnCodes DeleteAttribute (const char* name); EreturnCodes DeletePvtAttribute 
(const char* 

name ) ; /***********+********************************************^ / / RemoveA 

will remove the named attribute from the container //DX_CommonObject or 
DX_ListObject but will not delete the named //attribute's 
pointer /****************************************** 

EreturnCodes RemoveAttribute (const char* name); EreturnCodes Remove Pvt At tribute 
(const char* 

name); //Do NOT 

delete the pointer that is returned to you, it still is owned by //the container 
DX_CommonObject or DX_ListOb ject . You CAN use the any of //the attribute class 
methods for the 

pointer void* 
GetAttribute (const char* name); void* GetPvtAttribute (const char* name); void 
PrintContents ( ) ; //The caller of Demarshal is responsible for object's memory 
allocation static DX_CommonOb j ect* Demarshal (char* ObjOid, int type, int 
Contextlndex) ; EreturnCodes Marshal (int type, int Contextlndex) ; static 
EreturnCodes DeleteStorage (const char* oidVal, int type, int Contextlndex); //The 
caller of GetOID is responsible for deleting the memory of the returned char* char* 
GetOID(); EPriorityCode GetPriority ( ) ; protected: void* Find(const char* name); 
static . EreturnCodes RestorePersistentOb ject (const char* oidVal); static 
EreturnCodes DeletePersistentObject (const char* oidVal, int type); private: //Data 
Members DX_ListOb ject* PrivateList; DX_ListObj ect* PublicList; static void Delete 

(RWDlistCollectables* list); static int Copy (RWDlistCollectables* dest, const 
RWDlistCollectables *src); static EreturnCodes CopyPersistentOb ject (char* 
filename); static EreturnCodes CopyFile ( char* filename, char* copyf ilename) ; void 
saveGuts (RWFile& file) const; void saveGuts (RWvo streams stream) const; void 
restoreGuts (RWFile& file); void restoreGuts (RWvistream& stream); const int check() 
const; DX_Boolean updateListOids (DX ListObject* Plist, DX_OID *Poid) ; DX^Boolean 
updateObjectOids (DX CommonOb j ect* Pob j , DX_OID *Poid) ; DX_Boolean ValidateNaming 

(const char* name); #ifdefDX_DAT ABASE EreturnCodes InsertlntoTable (char* filename, 
int Contextlndex); static EreturnCodes RetrieveFromT able (char* filename, char* old, 
int Contextlndex); EreturnCodes UpdateTable (char* filename, int Contextlndex); 
#endif //use to cal . the number of bytes needed to store an object using RWFile 
RWspace binaryStoreSize ( ) const;); }; 

Detailed Description Paragraph Table (34) : 

class: DX_QueueLogMgr { public: // create an instance of the object by calling the 
constructor // delete using Deletelnstance ( ) static DX_QueueLogMgr* Instance (char* 
ComponentName=0) ; // delete the object static void Deletelnstance ( ); // Checks if 
the QueueStatusList has an entry // for the particular queue and if so checks // if 
the entry indicates whether the // queue monitoring is on or off and logs the // 
QueueObject accordingly static void DumpQLog (EQueueOperation op, char* queueName, 
DX_QueueOb ject* qo) ; // if you want to monitor a queue, an entry in // the queue 
status list should be created first // by giving the queue name and the pid. The 
function // reads the . reg file and initializes the entry // accordingly. 
EreturnCodes InsertQueueStatusList (char* QName, int pid); // if queue monitor 
changed the queue registration file, reset the // object, read the reg file and 
update the queueStatusList; EreturnCodes Reconf igQueueStatusList ( ); private: 
DX_Mutex* listLock; static DX_QueueLogMgr* instance; char ComponentName 
[MAX_NAME_LEN] ; char QlogDir [MAX_FILE_NAME ] ; DX_QueueLogMgr ( char* 

inComponentName=0, char* qlogdir=0) ; virtual . about . DX_QueueLogMgr ( ); EreturnCodes 
DeleteFromRegFiles (char* ComponentName, int pid); DX_INDICATOR GetStatusFromRegFile 
(char* regFileName, int& regFileExists) ; char* GetQRegFileName (char* QName); 
EreturnCodes FindQueueLogStatusInf o (char* inQName, DX_QueueLogStatusInf o** copy) ; 
RWDlistCollectables *queueStatusList ; }; class DX_QueueLogStatusInf o : public 
RWCollectable { friend class DX_QueueLogMgr; private: char qName [MAX_NAME_LEN] ; 
DX_INDICATOR qLogStatus; char qLogFileName [MAX_FILE_NAME ] ; RWDECLARE_COLLECTABLE 
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(DX_QueueLogStatusInfo) ; DX_QueueLogStatusInf o ( ){ }; /^^uring construction if 
inQLogStatus is ON // open the logStream for QName.qlog in directory 
DX_HOME/DX_QLOG DX_QueueLogStatusInf o ( char* inQName, DX_INDICATOR inQLogStatus, 
char* qlogdir) ; // close all the streams which are 

open . about. DX_QueueLogStatusInfo( ); char* GetQName ( ); DX_INDICATOR GetQLogStatus 
( ); char* GetQLogFileName { ); // if set to on, open stream, if set to off close 
the stream EreturnCodes SetQLogStatus (DX_INDICATOR inStat) ; }; #define DX_QLOG 
(QueueOp, QueueName, qo) DX_QueueLogMgr : : .backslash. DumpQLog (QueueOp, QueueName, qo) ; 

Detailed Description Paragraph Table (43) : 

class: DX_QueueManager { friend class DX_QueueTransaction; friend class DX_DBQueue; 
friend class DX_Monitor; public: static DX_QueueManager* Instance (const char* 
ProcessName, EstorageTypes type); static void Deletelnstance ( ); static 
DX_QueueManager* Get Instance 

( J - //Queue 
operation 

interface /****************************************** / 

label and comment arguinents will be used for Queue Administration Purpose. //So 

queue administration GUI will also see the name and comment of each CO in 

the //queue. They can be type of UTF-8 encoded string, 7-bit ASCII string or wide 

string. //User should not delete pointer to DX_CommonOb ject after call 

Enqueue /***************************************************** 

EreturnCodes Enqueue (const char* qName, DX_CommonOb ject &co, DX_QueueTransaction 
&transaction, const char* oLabel, const char* comment, EPriorityCode priority = 
NORMAL); EreturnCodes Enqueue (const char* qName, DX_CommonOb ject &co, 
DX_QueueTransaction &transaction, const UNICHAR* oLabel, const UNICHAR* comment, 
EPriorityCode priority = 

NORMAL) ; /**************************************************** //Caller 
should free non-NULL pointer to DX_CommonOb j ect //Return SUCCESS if Dequeue 
returned a common object //Return FAILED if Dequeue returned a NULL common object 
pQ /****************************************************** 

EreturnCodes Dequeue (const char* qName, DX_CommonOb ject* &C0 DX_QueueTransaction 
&transaction) ; EreturnCodes Dequeue (const char* qName, const char* objID, const 
char* obj Label, DX_CommonOb ject* &co, DX_QueueTransaction 

&transaction) ; /************************************************* // 
caller of GetCursor is responsible for deleting //returned DX_IndexOb ject* 
pointer . /*********+*************************************** 

DX_IndexOb ject* GetCursor (const char* qName, EPriorityCode priority = 

INTERACTIVE) ; /***-***************************************************** / /W 

set the cursor to the EPriorityCode passed 

in /******************************************************^ EreturnCodes 
ResetCursor (DX_IndexObject &cursor, EPriorityCode priority = 

INTERACTIVE) ; /************************************************** //T 
always is a non-null DX_QueueList returned //Caller should delete 

DX_QueueOb j ectList returned // //NOTE: DX_QueueList may be empty if no entries were 
found // //USAGE: //GetQueueView (DX_QueueObj ectList* &list DX_IndexOb j ect 
&QViewCursor, // int size = 0) //will return #entries =< size for EPriorityCode of 
QViewCursor and ALL lower priorities // //GetQueueView (DX_QueueObj ectList* &list, 
EPriorityCode priority, // DX_IndexOb j ect &QViewCursor , int size = 0) //will return 
#entries =< size for EPriorityCode of priority, QViewCursor is updated to //reflect 
position of last retrieved 

EreturnCodes GetQueueView (DX_QueueObj ectList* &list, DX_IndexOb j ect &QViewCursor, 
int size = 0; EreturnCodes GetQueueView (DX_QueueObj ectList* &list, EPriorityCode 
priority, DX_IndexObj ect &QViewCursor , int size = 

Qj. //Caller 
should free char** returned 

twice /*****************************************************"**** char* * 

GetManagedQueueNames (int& number); char** GetAllQueueNames (int& number); private: 
static DX_QueueManager* instance; char* owner; EstorageTypes Implementation; char* 
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FileDBDirectory; RWGDlist (DX_Queue) QueueList; DX_Mutex* mutex; DX_QueueManager 
(const char* processID, EstorageTypes type, const char* FileDBDir) ; 
. about . DX_QueueManager ( ); //Extended transaction support interface EreturnCodes 
Commit (DX_QueueTransaction &transaction) ; EreturnCodes Rollback (DX_QueueTransaction 
Stransaction) ; //Queue administration interface EreturnCodes DeleteQueue (const 
char* qName) ; EreturnCodes FlushQueue (const char* qName) ; EreturnCodes FlushQueue 
(const char* qName, EPriorityCode priority) ; EreturnCodes Remove FromQueue 
(DX_QueueOb ject *object) ; //Performance monitor interface //the memory of 
pNumOfMsgProcessed, pAvgMsgCacheTime, pAvgMsgProcessTime //should be allocated 
before invoking this method. EreturnCodes GetQueuePerf ormance (char * inputQName, 
long *pNumOfMsgProcessed, double *pAvgMsgCacheTime, double *pAvgMsgProcessTime, 
DX_Boolean resetFlag = TRUE); void ResetAll (const char *qNameList) ; EreturnCodes 
GetDBTableSpaceUsage ( float &usage) ; //Internal use DX_Queue* FindQueue (const char* 
qName); DX_Queue* CreateQueue (const char* qName); }; 

Detailed Description Paragraph Table (46) : 

class: DX_FileSubQueue { friend class DX_FiIeQueue; friend class DX_QueueManager ; 
private: DX_FileSubQueue (const char* qName, EPriorityCode pCode, const char* 
FileDBDir); . about . DX_FileSubQueue ( ); EreturnCodes Enqueue ( DX_CommonObj ect& co, 
const char* Processid, const char* label, const char* comment) ; DX_CommonObject* 
Dequeue (DX_IndexOb ject & io) ; DX_CommonObiect* Dequeue (DX_IndexOb ject & io, const 
char* ObjectID, const char* Ob j ectLabel) ; EreturnCodes Commit (DX_QueueOperation& 
oper); EreturnCodes CompleteCommit (DX_QueueOperation& oper) ; EreturnCodes Rollback 
(DX_QueueOperation& oper); EreturnCodes DestroyStorage ( ); EreturnCodes Flush ( ); 
EreturnCodes RemoveOb ject (DX_QueueOb j ect* qOb j ) ; EreturnCodes GotoBeginning 
(DX_IndexOb ject& cursor); EreturnCodes GetQueueView (DX_IndexOb j ect &cursor, 
DX_QueueObjectList* &list, int size); //used by the performance monitor long 
GetNumOfMsgProcessed ( ); double GetTotalMsgCacheTime ( ); double 

GetTotalMsgProcessTime ( ); void Reset ( ); private: char* QueueName; EPriorityCode 
Priority; char* QueueFileName; char* IndexDirectory; int startFilelndex; int 
endFilelndex; //These two fields are used for Dequeue operation and always go 
forward int currentFilelndex; int currentRecordlndex; int lastRecordlndex; 
DX_QueueObjectList BufferList; ////////////////////////// //Internal use 
only ////////////////////////// EreturnCodes EnqueueCommit (DX_QueueOperation 
&oper) ; EreturnCodes DequeueCommit (const char* old, const DX_IndexOb j ect* io) ; 
EreturnCodes CompleteEnqueueCommit (DX_QueueOperation &oper) ; EreturnCodes 
CompleteDequeueCommit (const char* oid, const DX_IndexOb j ect* io) ; EreturnCodes 
EnqueueRollback (const char* oid, const DX_IndexObject* io) ; EreturnCodes 
DequeueRollback (const char* oid, const DX_IndexOb j ect* io) ; EreturnCodes 
TryRecycleFile (int findex) ; void TryRecycleQueue ( ); char* GetFileName ( int findex) ; 
int OpenFile(int whichFile) ; EreturnCodes CreatEndFile ( ); void UpdatelndexFile ( ); 
void UpdateFilelndex ( ); EreturnCodes ExpandQueue ( * ) ; EreturnCodes MarkOb j ectlnFile 
(const DX_IndexOb ject* iOb j , EQueueOb j ectStatus status); //Unix does not have low- 
level eof 10 function available int IsEOF(int fd) ; //used by performance monitor 
double totalMsgCacheTime; double totalMsgProcessTime; long numOfMsgCommited; void 
SetDequeueTime (DX_QueueObject *qo) ; void SetEnqueueTime (DX_QueueOb ject *qo) ; void 
CompleteCommitCalculation (DX_QueueObject *qo) ; }; 

Other Reference Publication (3) : 

Greenbaum, J. , "Competitve Linking Update : CrossRoads to the Rescue," Hurwitz 
Balanced View Research Bulletin, 6 pgs. (Jun. 1997) . 



http://westbrs:9000/bin/gate.exe?f=doc&state=8f8002.12.1&ESNAME=KWI^ 2/24/04 



